view release on metacpan or  search on metacpan

script/epan  view on Meta::CPAN

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

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

=head2 C<create> 

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

=head2 C<index>

Regenerate the index so that tools like C<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. C<add> or C<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
C<cpanm>:

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

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

In these cases, if you want to prepare a pack of modules to carry with your
application, you can do like this:

   $ figure_out_modules > modlist
   $ cpanm -L xxx --save-dists dists $(<modlist)
   $ epan index -t dists
   $ tar cvf dists.tar dists

Well, put like this the second and third lines can just be synthesized as:

   $ epan add -t dists $(<modlist)

but you get the idea. The directory with the modules might be the
byproduct of invoking C<carton> instead (in which case you would end up
with a sub-directory C<cache>).

Anyway, you can then carry dists.tar with you, at which point you can:

   $ cpanm --mirror file://$YOURPATH --mirror-only Mod1 Mod2 ...

This command expects the target directory to exist and will complain
otherwise.

=head2 C<inject>

If you have some local distribution files, e.g. generated by yourself and
not (yet) uploaded to CPAN, you can inject them into a local EPAN. The
syntax is straightforward:

   epan inject \ 
      [-a|--author author-name] \
      [-t|--target dirname] File1 [File2...]

As for many other commands, you can also set the different output
filenames, but that would be hardly useful.

=head2 C<list-actions> and C<list_actions>

Prints out the list of available commands.

=head2 C<list-obsoletes> and C<list_obsoletes>

   epan list-obsoletes [-t|--target dirname]

Prints out a list of obsolete distributions in the EPAN. A distribution is
considered I<obsolete> if there is a newer corresponding version in the
EPAN. E.g. suppose that you work on C<Acme::Whatever> and inject version
C<0.2>:

   epan inject Acme-Whatever-0.2.tar.gz
   # ...

then you work on it some more time, and inject version C<0.3>:

   epan inject Acme-Whatever-0.2.tar.gz
   # ...

Now your EPAN contains two distribution packages for C<Acme::Whatever>,
one for release C<0.2> (which is the obsolete one) and one for the newest
version C<0.3>.

=head2 C<purge-obsoletes> and C<purge_obsoletes>

   epan purge-obsoletes [-t|--target dirname]

Remove (purge) obsolete distribution packages from the EPAN. See above for
what I<obsolete> means.

=head1 OPTIONS

The following options are supported, even though not all actions use them
all:

=over

=item -1 | -m | --mailrc

path to the file C<01mailrc.txt.gz>, defaults to
C<authors/01mailrc.txt.gz> inside the target directory. You hardly want to
change this.

=item -2 | -o | --output | --package-details

path to the file for C<02packages.details.txt.gz>, defaults to
C<modules/02packages.details.txt.gz> inside the target directory. Yes, you
can use C<-> with the I<usual> meaning, although this might not help you
much.