|
•Re:identifying module dependiencies
by merlyn (Sage) on Jun 11, 2004 at 15:22 UTC
|
You mean like Module::Depends?
update:
Of course, I was actually thinking of (and had used) Module::ScanDeps, but that doesn't come up on a search.cpan.org with "depends". {sigh} | [reply] |
Re: identifying module dependiencies
by Happy-the-monk (Canon) on Jun 11, 2004 at 15:22 UTC
|
Is there an area/mechanism of cpan that will give you a concise list of a module's dependencies?
Module::Depends?
Cheers, Sören
| [reply] |
|
|
You've both pointed me in the right direction... If I'm looking at SOAP::Lite it doesn't appear any easy way of viewing dependencies because there's no META.yml within its package after I extract it out.(other than attempting to build it and letting the make output complain about what it is missing?)
I did take a peek at the modules Archive::Tar and Archive::Zip (I brought them up through search.cpan.org). They both list META.yml as "Special" files. So this would seem the answer to the problem, but mileage varies depending upon the module - whether or not the author's generates a META.yml file? Any more info/insights/corrections are welcome. Thanks!
| [reply] |
Re: identifying module dependiencies
by eXile (Priest) on Jun 11, 2004 at 15:40 UTC
|
perl -l -MSOAP::Lite -e 'foreach (keys %INC) {s#/#::#g; chop;chop;chop
+; print}'
Will give you the modules used by SOAP::Lite. | [reply]
[d/l] |
|
|
Okay, I thought that was a CUFP++. I've added that to my shell aliases (and it appears you can put the -M after the -e incantation, which was a surprise). Thanks!
--
[ e d @ h a l l e y . c c ]
| [reply] |
Re: identifying module dependiencies
by jZed (Prior) on Jun 11, 2004 at 15:50 UTC
|
AFAIK, Module:Depends a) requires that the module in question has a Meta.YAML file and b) only checks what modules are required to make and load the module. This will miss, for example, modules that do on-the-fly requiring i.e. that depend on another module in certain situations but do not depend on that other module for just making and loading the original module. | [reply] |
|
|
a) requires that the module in question has a Meta.YAML file
That's why there's Module::Depends::Intrusive :-)
b) only checks what modules are required to make and load the module. This will miss, for example, modules that do on-the-fly requiring i.e. that depend on another module in certain situations but do not depend on that other module for just making and loading the original module.
True, but it's impossible to determine this programatically in the general case. The other issue is that it conflates build-time, test-time and run-time dependencies. If you're dealing with PPMs, for example, you don't really care about build- or test-time dependencies.
| [reply] |
|
|
It does seem an imperfect science, only useful to the extent that module authors implement it.
What inspired the question was that I'm trying to build/install perl with all the modules I need, but before doing the actual work I wanted to document it all first. Pull all the files at once, and then build/install them all one by one in the most sensible order. I thought about creating a spreadsheet listing the modules I want, and each's dependencies - but why do that work manually if there's a dynamic means. Dynamic would be more accurate.(and less work)
Looks like this is the spec for the META.yml files. It does support a "recommended" state which is probably where those modules you mention that are only used in certain circumstances but not strict dependiences would fit.
| [reply] |
Re: identifying module dependiencies
by wolv (Pilgrim) on Jun 12, 2004 at 11:13 UTC
|
There is also Module::ScanDeps, which is used by PAR to do this kind of thing. It's not perfect by any means, since it doesn't really run the script, but it's one solution. | [reply] |