Beefy Boxes and Bandwidth Generously Provided by pair Networks
more useful options
 
PerlMonks  

help managing modules using CPAN.pm

by j3 (Friar)
on Nov 13, 2006 at 17:24 UTC ( #583768=perlquestion: print w/ replies, xml ) Need Help??
j3 has asked for the wisdom of the Perl Monks concerning the following question:

I'm using Perl on Debian, had a look at the CPAN.pm docs, but still have some questions.

1. How do I uninstall modules?

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?

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

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?

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 [update|upgrade]"?

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?

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?

Comment on help managing modules using CPAN.pm
Re: help managing modules using CPAN.pm
by tirwhan (Abbot) on Nov 13, 2006 at 17:37 UTC

    Take a look at dh-make-perl, which allows you to easily created Debian .deb packages from CPAN modules. You can then install these normally with dpkg and uninstall with apt-get remove. You'll have to manage dependencies and upgrades yourself, but this is still the best way I've found to manage those perl modules not available in the Debian distribution.


    All dogma is stupid.
      {snip} but this is still the best way I've found to manage those perl modules not available in the Debian distribution.

      Can CPAN.pm tell when dependencies are already met by modules previously installed via apt-get?

      I'm guessing that, of course, apt-get cannot tell when dependencies are already met by modules previously installed via CPAN.pm.

        That's exactly right - CPAN.pm checks for deps by looking at what's installed, regardless of how it got there. apt-get, on the other hand, looks at what dpkg packages are installed
        Can CPAN.pm tell when dependencies are already met by modules previously installed via apt-get?

        Of course! CPAN is a Perl program. If apt-get didn't install the Perl modules correctly, other Perl code couldn't see them.

        I'm guessing that, of course, apt-get cannot tell when dependencies are already met by modules previously installed via CPAN.pm.

        I believe that's correct as well.

        I'm guessing that, of course, apt-get cannot tell when dependencies are already met by modules previously installed via CPAN.pm.

        This is correct, unless you create .deb packages from your CPAN modules before installing them, as I recommended above.

        An example, you'd like to install Frobnicator::Simple from CPAN, which is not available from any apt repository. So you run dh-make-perl which creates the package libfrobnicator-simple-perl-<version>.deb and you install that package. Any supsequent packages which you install via apt-get will know that libfrobnicator-simple-perl has been installed, and should you install an additional package that depends on (or conflicts with) this module, apt will be able to do the right thing.

        Mind you, the situation won't come up too often, since generally packages in the apt repositories will only depend on other packages if they are also available via apt. And there is the additional possible corner case that a package you want to install depends on a different version of libfrobnicator-simple-perl than the one you've installed by hand, and the maintainer of that package forgot to specify that when rolling it. But that should be even rarer.


        All dogma is stupid.
Re: help managing modules using CPAN.pm
by grep (Monsignor) on Nov 13, 2006 at 18:20 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).

    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

      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?

        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
        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".

Re: help managing modules using CPAN.pm
by nicholasrperez (Monk) on Nov 13, 2006 at 20:47 UTC
    This is an issue that was recently discussed in yast vs cpan in which I offered this comment.

    I actually use Debian, too (unstable x86-64, aka etch), but the comments in that node are relevant to any distro. I'll reiterate only a little bit here: Have a completely separate development space. Let Debian do its own thing with regards to modules and you keep your own compiled perl and CPAN'd modules somewhere saparate (your ~/ maybe?).

      Ah... that sounds like a very good idea. Thank you. I could then keep a log of of every module installed, so that the installation could be easily reproduced if necessary (either on other machines, or if I somehow manage to befoul this one and need to replace it).

      (your ~/ maybe?)

      Actually, I tend to put bigger stuff like this into their very own /opt/foo directory, with the source tucked away in /opt/src. This has a nice side-effect of making uninstallion a snap (well, a "cd /opt; rm -fr foo" anyway :) ).

Re: help managing modules using CPAN.pm
by Anonymous Monk on Nov 14, 2006 at 12:01 UTC
    1. It's in very rare events that CPAN modules need to be uninstalled, in my experience manually deleting the .pm/.xs, etc files in @INC works best. Although, you see many people will disagree and have gone so far as to write modules to assist in this operation.

    2. Configuring CPAN is a necessary burden, also I don't think closing your eyes and picking a random mirror has a significant impact, I just choose the well-known (or seemingly well known) mirrors.

    3. Some CPAN packages in the debian package pool are outdated, some by months/in excess of 2 or more revisions. I was amazed to find out just how many seem are actually outdated when i used the CPAN shell to upgrade. Also, debian-perl maintainers might be inclined to choose a different package to satisfy a dependancy when infact you might already have the necessary header files available locally (from other source or debian packages). In my opinion, CPAN/CPANPLUS seems to be the way to go - configuring from source and all that, it's definitely longer and sometimes requires manual interaction but since CPAN.pm is a perl module, it means installing perl modules from within perl script is possible.
    #!/usr/bin/perl -Wl use CPAN; while (<DATA>) { chomp; install $_; } __DATA__ Foo::Bar Foo::Baz Foo::Quux
    5.  perl -MCPAN -e upgrade
    6. CPAN isn't as bleeding edge as CPANPLUS but it's definitely still chugging along. Michael Schwern, author of Module::MakeMaker seems to suggest using CPANPLUS vehemently, quite plausibly because CPANPLUS has better support for Module::Build and also because it's just pretty much better structured than CPAN (which could do with a complete rewrite). I should think CPAN and CPANPLUS will continue to live on contending, just as GNOME/KDE, Firefox/IE, etc.

    7. It's quite hard to botch up on installing perl modules, even if you should, leaving them be isn't going to impact you in any significant way unless they were incompletely installed. In any case, using a 'forced install' of CPAN::install() seems to effectively reinstall those modules (with the added disadvantage of test errors being turned into warnings).
    perl -MCPAN -e shell # or /usr/bin/cpan > force install Foo::Bar Foo::Baz Foo::Quux
Re: help managing modules using CPAN.pm
by bart (Canon) on Nov 14, 2006 at 12:32 UTC
    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?
    Some monks here have been working on that — or, in my case: been thinking about it. I think Intrepid actually got the furthest making progress: IIRC he actually got a script to ping CPAN mirrors and then select some.

Log In?
Username:
Password:

What's my password?
Create A New User
Node Status?
node history
Node Type: perlquestion [id://583768]
Approved by ikegami
Front-paged by andyford
help
Chatterbox?
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others musing on the Monastery: (5)
As of 2014-07-12 09:55 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    When choosing user names for websites, I prefer to use:








    Results (239 votes), past polls