App-EPAN

 view release on metacpan or  search on metacpan

README  view on Meta::CPAN

       epan index
          [-1|-m|--mailrc path]
          [-2|-o|--output path]
          [-3|-l|--modlist path]
          [-t|--target dirname]
    
       # "inject" adds local distribution archives available as files
       epan inject
          [-1|-m|--mailrc path]
          [-2|-o|--output path]
          [-3|-l|--modlist path]
          [-a|--author name]
          [-t|--target dirname]
          File1 [File2...]
    
       # "list-actions" is also "list_actions"
       epan list-actions
    
       # "list-obsoletes" is also "list_obsoletes"
       epan list-obsoletes [-t|--target dirname]
    
       # "purge-obsoletes" is also "purge_obsoletes"
       epan purge-obsoletes [-t|--target dirname]
    
       # "update" is also "add" and "install"
       epan update
          [-1|-m|--mailrc path]
          [-2|-o|--output path]
          [-3|-l|--modlist path]
          [-t|--target dirname]
          Module1 [Module2...]

EXAMPLES

       # collects all what's needed to install Template::Perlish somewhere
       shell$ epan create -t mymodules Template::Perlish
    
       # regenerate index in ./modules/02packages.details.txt.gz
       shell$ epan idx -t mymodules
    
       # prints index on standard output, works on /path/to/minicpan
       shell$ epan index -o - -t /path/to/minicpan

DESCRIPTION

    This program helps you creating and managing an EPAN - a version of the
    CPAN that is trimmed down to your needs for installing specific stuff.

    To start with an example, suppose you have to install Mojolicious and a
    couple of its plugins in a machine that - for good reasons - is not
    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:

       $ ./install.sh /path/to/local/perl

    The program epan is actually a unified access point to several
    different tools for manipulating your exclusive Perl archive nook. Most
    of these commands operate upon a target directory that is where your
    EPAN is stored; this can be specified via option -t or its longer
    version --target. By default, the target directory is assumed to be
    epan in the current directory.

 add, install and update

    These commands are synonimous in epan, and all help you pull a module
    and its dependencies from a CPAN mirror right into your EPAN,
    regenerating the index at the end of the process. The syntax is:

       epan add # or install or update \
          [-t|--target directory]
          Module1 [Module2...]

    So, in addition to the common option -t for setting the right target
    directory, it accepts a list of module names to install (with their
    dependencies).

 create

    This command is almost the same as add and its aliases, with the
    exception that the target directory MUST NOT already exist when called.

 index

    Regenerate the index so that tools like cpanm are happy about what they
    find and treat your target directory as a real CPAN sort-of mirror. The
    syntax is the following:

       epan index [-t|--target dirname]

    Note that other commands (e.g. add or create) already do the indexing.
    This command can be useful when you have a starting base (i.e. a
    compound of modules coming from CPAN and your own distribution) already
    arranged in the right directory tree, but you need to generate an
    index. For example, this happens when you collect some distribution
    files using cpanm:

       shell$ cpanminus -L xxx --save-dists dists Mod1 Mod2...

    because it saves the needed distributions in dists but it does not
    generate the index. The same happens when using carton.

    In these cases, if you want to prepare a pack of modules to carry with



( run in 1.614 second using v1.01-cache-2.11-cpan-39bf76dae61 )