App-EPAN
view release on metacpan or search on metacpan
connected to the Internet. It's easy to get the distribution files for
Dancer and the plugins... but what about the dependencies? It can
easily become a nightmare, forcing you to go back and forth with new
modules as soon as you discover the need to install them.
Thanks to cpanm, this is quite easier these days: it can actually do
what's needed with a single command:
# on the machine connected to the Internet or to a minicpan
$ cpanm -L xxx --scandeps --save-dists dists \
Mojolicious Mojolicious::Plugin::Authentication IO::Socket::SSL ...
which places all the modules in subdirectory dists (thanks to option
--save-dists) with an arrangement similar to what you would expect from
a CPAN mirror.
On the target machine, you still have to make some work - e.g. you
should collect the output from the invocation of cpanm above to figure
out the order to use for installing the distribution files.
Additionally, the directory structure that is generated lacks a proper
index file (located in modules/02package.details.txt.gz) so it would be
difficult to use the normal toolchain.
epan aims at filling up the last mile to get the job done, providing
you with a subdirectory that is ready for deployment, with all the bits
in place to push automation as much as possible. So you can do this:
# on the machine connected to the Internet or to a minicpan
$ epan create Mojolicious Mojolicious::Plugin::Authentication \
IO::Socket::SSL ...
$ tar cvzf epan.tar.gz epan
transfer dists.tar.gz to the target machine and...
# on the target machine
$ tar xvzf epan.tar.gz
$ cd epan
$ ./install.sh
optionally providing an installation target directory:
script/epan view on Meta::CPAN
connected to the Internet. It's easy to get the distribution files for
Dancer and the plugins... but what about the dependencies? It can easily
become a nightmare, forcing you to go back and forth with new modules as
soon as you discover the need to install them.
Thanks to L<cpanm>, this is quite easier these days: it can actually do
what's needed with a single command:
# on the machine connected to the Internet or to a minicpan
$ cpanm -L xxx --scandeps --save-dists dists \
Mojolicious Mojolicious::Plugin::Authentication IO::Socket::SSL ...
which places all the modules in subdirectory C<dists> (thanks to option
C<--save-dists>) with an arrangement similar to what you would expect from
a CPAN mirror.
On the target machine, you still have to make some work - e.g. you should
collect the output from the invocation of cpanm above to figure out the
order to use for installing the distribution files. Additionally, the
directory structure that is generated lacks a proper index file (located
in F<modules/02package.details.txt.gz>) so it would be difficult to use
the normal toolchain.
L<epan> aims at filling up the last mile to get the job done, providing
you with a subdirectory that is ready for deployment, with all the bits in
place to push automation as much as possible. So you can do this:
# on the machine connected to the Internet or to a minicpan
$ epan create Mojolicious Mojolicious::Plugin::Authentication \
IO::Socket::SSL ...
$ tar cvzf epan.tar.gz epan
transfer C<dists.tar.gz> to the target machine and...
# on the target machine
$ tar xvzf epan.tar.gz
$ cd epan
$ ./install.sh
optionally providing an installation target directory:
( run in 0.431 second using v1.01-cache-2.11-cpan-4d50c553e7e )