Beefy Boxes and Bandwidth Generously Provided by pair Networks
Welcome to the Monastery
 
PerlMonks  

Re: help managing modules using CPAN.pm

by grep (Monsignor)
on Nov 13, 2006 at 18:20 UTC ( [id://583786]=note: print w/replies, xml ) Need Help??


in reply to help managing modules using CPAN.pm

1. How do I uninstall modules?

uninstalling modules should give you some hints. But I personally never uninstall modules (unless there is a big problem), and I install quite a few to look at and test out. They're generally small (disk space is cheap) and generally don't conflict with each other. On the very rare occasion I do uninstall a module - I do it by hand (IIRC I've only done that once over 8+ years).

2. When I run CPAN.pm's shell for the first time, among the list of questions it asks, it wants me to tell it which mirrors to use. In North America, USA, there's about 62 url's from which to choose. Is there some option at this point to simply ask CPAN.pm to ping some of them and automatically select the quickest and least burdened ones?

Not that I know of. But geographic info is often in the mirror name for .edu's. That and you can pick quite a few and if you start having a problem it fairly easy to get back into the CPAN config.

3. Is it more common for most Perlers to just install modules by-hand and not even bother with CPAN.pm (or CPANPLUS)?

I generally install by CPAN but about 1/4 of the time tests will fail. I then revert to installing by hand to see what tests fail and if I'm concerned about them. The nice thing about this is usually, most of the dependacies are taking care of by CPAN and I just have to do the orginal module by hand. Almost all the test failures I see are on the actual module I'm trying to install and rarely the dependancies.

4. On Debian, most modules I need are usually already available via apt-get. I'm guessing it's asking for a big mess to alternately use apt-get and CPAN.pm for the same Perl installation. What do most Debian users do regarding CPAN.pm?

I can't say anything about apt-get but I do get some large/complex modules (WX modules, GTK* modules by rpm and yum. This has never caused me a problem and saved a bit of time finding external depenancies and compiling.

5. How do I keep my CPAN.pm-installed modules up-to-date? In other words, what's the equivalent of Debian's "apt-get upgrade"?

There is the upgrade command from CPAN. But be careful. You need to watch modules you heavily depend on (like DBI and your DBD's, and DBIx::Class) for interface changes. I wouldn't use any kind of automation for this /me is paranoid

6. According to the docs at perldoc.org, development of CPAN.pm is stalled and the module may eventually be replaced by CPANPLUS. However, search.cpan shows that both distributions seem to be pretty current. Will CPANPLUS still probably eventually replace CPAN.pm?

CPAN seems to be going along. I just sent a bug report and got a reply from Schwern in a day.

7. Finally, if I think I've completely botched up things using CPAN.pm, how can I wipe out everything that was installed by CPAN.pm? That is, is there a simple "rm -fr" I can do to start from scratch without touching the rest of my Perl installation?

Not that I know of, but I would doubt you could ever get to that point. CPAN makes it pretty easy. You may get into a problem with one module, but if you take your time it's pretty easy to get rid of it by hand.

grep
Just me, the boy, two monks, and no questions asked

Replies are listed 'Best First'.
Re^2: help managing modules using CPAN.pm
by j3 (Friar) on Nov 13, 2006 at 20:05 UTC
    1. How do I uninstall modules?

    uninstalling modules should give you some hints. But I personally never uninstall modules (unless there is a big problem), and I install quite a few to look at and test out. They're generally small (disk space is cheap) and generally don't conflict with each other. On the very rare occasion I do uninstall a module - I do it by hand (IIRC I've only done that once over 8+ years).

    When you say "by-hand"... the times I've checked, I haven't seen a "make uninstall" target for the modules I've installed. Is that common (to not have an uninstall target)? If so, how do you uninstall?

    I generally install by CPAN but about 1/4 of the time tests will fail. I then revert to installing by hand to see what tests fail and if I'm concerned about them.

    Ahhh... I see. Thank you.

    But, when you say you "install by-hand", does that mean you go to where CPAN.pm downloaded the source files (umm... maybe somewhere in /root/.cpan?) and run "perl Makefile.PL..."? Or do you download a fresh archive?

    There is the upgrade command from CPAN. But be careful. You need to watch modules you heavily depend on (like DBI and your DBD's, and DBIx::Class) for interface changes. I wouldn't use any kind of automation for this /me is paranoid

    So, how exactly do you "upgrade by-hand" if you've already got the previous version installed? If I were going from using a 1.x to a 2.x, I'd want to make sure all the 1.x files were completely removed first, right?

      When you say "by-hand"... the times I've checked, I haven't seen a "make uninstall" target for the modules I've installed. Is that common (to not have an uninstall target)? If so, how do you uninstall?

      Uninstalling by hand means going to you lib/perl5/ and deleting the files. This can be dangerous, but if you take care it's easy and quick. But my main point was don't worry too much about uninstalling modules.

      But, when you say you "install by-hand", does that mean you go to where CPAN.pm downloaded the source files (umm... maybe somewhere in /root/.cpan?) and run "perl Makefile.PL..."? Or do you download a fresh archive?

      I download a fresh tarball from CPAN and extract (not that it should make a big difference from the .cpan). Then perl Makefile.PL (or Build.PL depending) -> make -> make test -> su -c 'make install' .

      So, how exactly do you "upgrade by-hand" if you've already got the previous version installed? If I were going from using a 1.x to a 2.x, I'd want to make sure all the 1.x files were completely removed first, right?

      Unless specified by the POD documentation you shouldn't have to worry about removing old modules. They should be overwritten. After install hundreds of modules I can't think of any real upgrade weirdness other than once with a big update to Class::DBI. But since I generally do upgrades one-at-a-time, it was easy to find out where to update my code.

      grep
      XP matters not. Look at me. Judge me by my XP, do you?

        Thanks grep!

      I have always used the method listed in the CPAN FAQ to remove unwanted modules.

      It is also possible to remove individual module files using:

      rm `perldoc -l Module::Name`

      Using the look command in the CPAN shell will drop you into that particular module's build directory so that you can run the installation commands 'manually'

      Using something like the following should upgrade modules removing conflicting module versions. Both CPAN and CPANPLUS can be configured to add the UNINST option when running make:

      perl Makefile.PL make make test make install UNINST=1
        That was a very pithy post bingos. Thank you for those details. :)
      I think that when you install a module, it stores the list of files it installs, somewhere in a text file. I forgot what it's called and I'm presently not at a computer where I can check. Sorry.

      But to uninstall, just delete each file listed in the file. Except... if the installation replaced an older version of the same module, and I mean physically replace: placing the files on top of the old ones, well this will obviously not restore the old files.

      I think you're then better off installing the old module over the new one, or at least have the archive ready in case it's an essential module to even be able to run CPAN.pm, so you can install them just using make and perl. Or install at a new location, delete the old files, and move the new files in place. Something like that.

      Yes a process like this should be automated, IMO.

      update I looked: the text file with the file listing is called ".packlist", and it resides somewhere under the "auto" root, in the module root where it's installed. For example, if the module is "Test::Pod" which is installed in "site/lib", then this file ought to be at "site/lib/auto/Test/Pod/.packlist".

Log In?
Username:
Password:

What's my password?
Create A New User
Domain Nodelet?
Node Status?
node history
Node Type: note [id://583786]
help
Chatterbox?
and the web crawler heard nothing...

How do I use this?Last hourOther CB clients
Other Users?
Others learning in the Monastery: (6)
As of 2024-04-23 22:45 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    No recent polls found