Do you have a question? Post it now! No Registration Necessary. Now with pictures!
- Posted on
- rm .cpan?
February 18, 2012, 7:28 pm
rate this thread
Re: rm .cpan?
(Small? When Oi were a lad all us had were 400K 40-track floppies...)
You want to keep .cpan/CPAN and .cpan/prefs (unless it's empty), since
they both contain irreplaceable preferences; and if you've generated any
bundles in .cpan/Bundle you need to check if you still want them.
Everything else can go, though of course it will need to be downloaded
again if you need it.
You may also want to look into App::cpanminus, which is much better
about not keeping things for too long. For one thing, it doesn't try to
keep a local copy of the metadata.
Re: rm .cpan?
Thanks Ben. You date yourself. Moore's Law has indeed been kind to us,
the early struggles notwithstanding.
Speaking of Bundle, I will eventually want to make a Bundle to speed up
the roll out of production machines (something I've not done before). I
gather I should do this BEFORE I remove anything?
I tried cpanm hoping that it would offer some mechanism to remove
targeted (unwanted) modules. It did not (or didn't work), so I just went
back to cpan.
Re: rm .cpan?
I've not really used CPAN's autobundle feature. I tend to make an effort
to keep even my private code in CPAN-style distributions with explicit
dependencies: it's a little harder to maintain at first, but enormously
easier to install later.
That said: all a bundle is is module file in a particular format. The
documentation is in perldoc CPAN, under "Bundles" (it's quite a long way
down). If you know which modules you want to install it's trivial to
create one yourself: just write a .pm with the appropriate pod in it,
and install it somewhere in @INC. Probably the best place would be
.cpan/Bundle, which is in @INC for CPAN.pm but not otherwise. Then you
can 'cpan Bundle::Whatever' and it will install all the modules in the
list (bundles are special-cased so their listed modules are always
reinstalled, even if the bundle itself is already installed.)
An alternative, which I find considerably more useful, is pip (from
CPAN). This will install private modules from tarballs as well as
public CPAN modules, and will let you depend on specific versions of
CPAN modules rather than always installing the latest. You do have to do
the work of building the list of modules you need yourself, though. (You
don't have to list *every* module, of course, just the ones your code
needs directly. pip knows how to follow dependencies from there onto
CPAN, even when it's building code that didn't come from there.)
Uninstalling is not a thing the Perl toolchain currently does at all
well, or indeed at all, much. It's a shame, because I think all the
information's there. You can use ExtUtils::Installed to find the
distribution a module belongs to, and to get a list of the files
installed from that distribution; uninstalling should then simply be a
matter of deleting all those files.
Of course, this will completely ignore any still-installed modules that
still depend on the modules you've just removed; and if the distribution
had replaced anything that came in the core you'll end up with a mess.
If you want to be able to uninstall things cleanly you need a proper
package management system, which CPAN.pm isn't. (For one thing, the
dependancy information doesn't exist after a module's been installed.)