http://www.perlmonks.org?node_id=455253


in reply to Re: How do you audit what Perl modules you use?
in thread How do you audit what Perl modules you use?

The node of merlyn's to which frodo72 was referring was this one, in case anyone was wondering.

PAR is useful when packaging up a Perl application. In my case I'm trying to find out what modules my application uses .. so I may just roll my own application.

Alex / talexb / Toronto

"Groklaw is the open-source mentality applied to legal research" ~ Linus Torvalds

Replies are listed 'Best First'.
Re^3: How do you audit what Perl modules you use?
by polettix (Vicar) on May 09, 2005 at 18:06 UTC
    Sure, but I've seen in the PAR documentation that it has some heuristic to decide which modules to include; this could be useful in your case, I think, because I hope they've already worked out the problem of eliminating modules that are distributed together with Perl, saving you time to reproduce such a behaviour.

    Update: I now see that the heuristic comes from Module::ScanDeps (this is in pp documentation).

    Flavio (perl -e 'print(scalar(reverse("\nti.xittelop\@oivalf")))')

    Don't fool yourself.
Re^3: How do you audit what Perl modules you use?
by talexb (Chancellor) on May 09, 2005 at 18:16 UTC

    Well, I tried installing PAR and got

    Warning: prerequisite Compress::Zlib 1.3 not found. We have 1.16.
    which puzzles me a little .. couldn't find version 1.3, only version 1.16? Isn't that a good thing? And there's no workaround?

    I guess I'll pass on PAR for now and go ahead with the brute-force method.

    Alex / talexb / Toronto

    "Groklaw is the open-source mentality applied to legal research" ~ Linus Torvalds

      Does 1.3 mean 1.3x? It goes up to 1.34 on CPAN

        Good question -- I don't know. I've abandoned PAR and I'm currently looking at Module::Dependency::Indexer as suggested by this node. It did mean I had to install a bunch of CPAN modules, and except for one pesky test that failed, the script at that location now compiles on my system.

        • I installed Module::Dependency::Indexer but it found that it needed GD, so I agreed with CPAN and said it could get that too.
        • CPAN asked me if libgd was installed in /usr/lib so I went and had a look and discovered that a) no it wasn't and b) I didn't have an RPM for that.
        • I downloaded and built libgd from here, and tried to continue the previous installation, but it failed.
        • Starting again, I tried to install Module::Dependency::Indexer but of course because of previous errors it failed, so I tried to install GD, but that failed too.
        • OK, so I had to do some cleanup, and I did a clean GD followed by a make GD, and that worked.
        • I had to do a clean Module::Dependency::Indexer and then make Module::Dependency::Indexer, test Module::Dependency::Indexer (this failed with #  t/03indexing.t line 36 is: ok( $i->{'depended_upon_by'}->2 eq 'c' );) and finally force install Module::Dependency::Indexer.
        • Are we there yet? No, because compiling the script also required Graph, and that required Heap.
        • Wait, there's still more, I also had to install Module::CoreList.

        Well, that doesn't happen every day, but for someone new to the language (and the sub-culture), it must be a little daunting.

        Alex / talexb / Toronto

        "Groklaw is the open-source mentality applied to legal research" ~ Linus Torvalds