in reply to A Guide to Installing Modules

++ for tachyon's nice introduction to module installation. Since I have already done about 600-700 tests for the CPAN-testers I would like to supply some comments (footnotes) from my experience.

Some Footnotes

1. In our days, fortunately most authors use h2xs and make dist. Therefore, these tarballs expand to Some-Module-0.01, and if you cd into the directory you don't have to search for the place to do your perl Makefile.PL.
Tarball distributions which expand just to Some are really a pain, especially if you download a few modules from the Some:: Namespace.
Unfortunately there are also some tarball distributions which don't get expanded in their own directories, but in the current directory -- Have fun with the cleanup afterwards.

2. Unfortunately, many CPAN authors are still not used to -- or don't know about -- setting PREREQ_PM in Makefile.PL. So be prepared to get the "Can't locate foo/bar.pm in @INC" error while running make test.

3. While you should find important information in the Readme File, don't be surprised if you just find a Readme template, where the author never cared to replace "blabla".

4. If make test just does one test (1..1) it is in most cases just a load test. This means, your module will get loaded without problems, but it does not tell you wether the supplied functions work as expected. While make test is a important step for confidence building you should test the Module with your own scripts, and report errors to the author if appropriate. Be prepared, that many tests supplied by the author do not test all functions.

Hanamaki

Edited by footpad, ~Wed Nov 28 20:04:16 2001 (GMT)

Replies are listed 'Best First'.
Re: Re: A Guide to Installing Modules
by Anonymous Monk on Dec 29, 2001 at 06:45 UTC
    How do you uninstall a module ?
[reply]
      If the module was installed in a normal fashion (perl Makefile.PL ...), it should've left a .packlist file.

      Then you just use ExtUtils::Installed (you could use File::Find, but why go through the trouble when somebody already done it) 

      use ExtUtils::Installed;
my $inst = ExtUtils::Installed->new();
print "$_\n" for $inst->files('CGI');

=head1 on my machine, I get

    C:\Perl\lib\CGI\Util.pm
    C:\Perl\lib\CGI\Cookie.pm
    C:\Perl\lib\CGI.pm
    C:\Perl\lib\CGI\Push.pm
    C:\Perl\lib\CGI\Pretty.pm
    C:\Perl\lib\CGI\Fast.pm
    C:\Perl\lib\CGI\Carp.pm
    C:\Perl\lib\CGI\Switch.pm
    C:\Perl\lib\CGI\Apache.pm

=cut

# and now for the "deletion" part
print "unlinking ", unlink( $inst->files('CGI') );

      [download]
      update:

      Hmm, works just fine for me on various perls/systems, what exactly did you try, and what version of ExtUtils::Packlist/ExtUtils::Installed do you have?

      How did you install Image::Magick?

      I have used CPAN to install modules and tested this, and it all works out as expected. I suspect one of the ExtUtils modules you're using is messed up. Seeing how you're still getting a file list, a workaround is easy (use File::Find to locate those files in @INC and acquire absolute paths).

      ____________________________________________________
      ** The Third rule of perl club is a statement of fact: pod is sexy.

[reply]
[d/l]
        I looked into it some further using the following: 
        #!/usr/bin/perl -w
use strict;
use ExtUtils::Installed;
my $inst = ExtUtils::Installed->new();
print map "$_\n", @ARGV
        ? map $inst->files($_), @ARGV
        : $inst->modules();
__END__

        [download]
        I got the same pathless reply for any module I checked - bar Perl itself. All additional modules were installed using CPAN. In reply to your requests:
        Read more... (3 kB)

        Makeshifts last the longest.

[reply]
[d/l]
[select]
        Hmm. On my 5.6.1 it looks like this: 
        Magick.so
Magick.pm
autosplit.ix
Magick.bs
Image::Magick.3

        [download]
        Not really suitable to feed it into unlink..

        Makeshifts last the longest.

[reply]
[d/l]
      Why would you need to?

      I don't believe there are any mechanisms available to completely uninstall a module (assuming it wasn't installed with a package management system like RPM). If you just want to make a module unavailable to scripts, just find and delete the Module.pm file.

[reply]

        I found at least one good reason to do this: if the code you are writing tests whether a module is available (through an eval { require Module;} and defaults to a less-than-optimal-but-acceptable behaviour if the eval returns an error. Then you need to test both cases, with and without the module. A workaround is to wrap the eval in a test controlled by an environment variable, so when testing you can pretend that the module was not here. This is not perfect (the module could be imported by an other part of yur code or by an other module) but it is usually the easiest way to "desinstall" a module.

[reply]

In Section Tutorials