Module dependencies
I want to find a nice, visual, automatic way of looking at my modules' dependencies. I want a script that I can give the name of a module and optionally a Perl version, and get a recursive list of its dependencies and their dependencies, maybe with highlighting to show which modules have never been in core, which modules are core in my Perl version, etc. Does such a thing or even a start at it exist? I'm sure I remember reading about something like this using Module::CPANTS but I can't find it now. Kake
Re: Module dependencies
On Mon, 8 Sep 2003, Kate L Pugh wrote: > I want to find a nice, visual, automatic way of looking at my modules' > dependencies. I want a script that I can give the name of a module > and optionally a Perl version, and get a recursive list of its > dependencies and their dependencies, maybe with highlighting to show > which modules have never been in core, which modules are core in my > Perl version, etc. > > Does such a thing or even a start at it exist? I'm sure I remember > reading about something like this using Module::CPANTS but I can't > find it now. Surely identifying the dependencies of any one module is incomputable in general, and most likely incomputable in the specific cases of many popular modules, especially those with baroque plugin architectures. Yay, I get to rain on Kake's parade again. S. -- Shevekhttp://www.anarres.org/ I am the Borg. http://www.gothnicity.org/
Re: Module dependencies
Shevek wrote: > > Surely identifying the dependencies of any one module is incomputable in > general, and most likely incomputable in the specific cases of many > popular modules, especially those with baroque plugin architectures. Of course that depends on whether you want to compute the dependencies yourself, or if you rely on metadata such as the Makefile.PLs and the META.yml files. -- Upward is not *NIX
Re: Module dependencies
On Mon, 8 Sep 2003, Rafael Garcia-Suarez wrote: > Shevek wrote: > > > > Surely identifying the dependencies of any one module is incomputable in > > general, and most likely incomputable in the specific cases of many > > popular modules, especially those with baroque plugin architectures. > > Of course that depends on whether you want to compute the dependencies > yourself, or if you rely on metadata such as the Makefile.PLs and > the META.yml files. I believe that there is a sufficient proportion of Makefile.PL files which compute dependencies rather than using a PREREQ_PM to make this an unpleasant task. S. -- Shevekhttp://www.anarres.org/ I am the Borg. http://www.gothnicity.org/
Re: Module dependencies
On 08/09/2003 at 13:15 +0100, Kate L Pugh wrote: I want to find a nice, visual, automatic way of looking at my modules' dependencies. [snip] I wonder how far a combination of Module::ScanDeps and Module::CoreList and a bit of wrapper code would get you? http://search.cpan.org/perldoc?Module::ScanDeps.pm http://search.cpan.org/perldoc?Module::CoreList -- :: paul :: historic light cone
Re: Module dependencies
Shevek wrote: >> Surely identifying the dependencies of any one module is incomputable in >> general, and most likely incomputable in the specific cases of many >> popular modules, especially those with baroque plugin architectures. On Mon 08 Sep 2003, Rafael Garcia-Suarez <[EMAIL PROTECTED]> wrote: > Of course that depends on whether you want to compute the dependencies > yourself, or if you rely on metadata such as the Makefile.PLs and > the META.yml files. Well, I was planning to rely on Module::CPANTS. I'd prefer an extant imperfect solution to an unimplementable perfect solution, or no solution. I'd like to be able to look at a relatively small report on a module, and go "aha! Foo::Bar only has a couple of dependencies, but one of those has jillions of non-core dependencies, and I'm only using a tiny part of the Foo::Bar functionality anyway, so let's see if there's a better way". I am really, really reluctant to add this to my already-huge to-do list and then find out someone already did it. Kake
Re: Module dependencies
On Mon, Sep 08, 2003 at 02:21:33PM +0100, Kate L Pugh wrote:
> Well, I was planning to rely on Module::CPANTS. I'd prefer an extant
> imperfect solution to an unimplementable perfect solution, or no solution.
I've used this in the past.
Obviously depends on Module::CPANTS being correct, but that's an SEP...
use Module::CPANTS;
my %seen;
my $data = Module::CPANTS->new->data;
print_requires('Class-DBI-0.93.tar.gz', 0);
sub print_requires {
my ($dist, $spc) = @_;
printf "%s%s\n", " " x $spc, $dist;
print_requires($_, $spc + 2)
foreach grep !$seen{$_}++, @{ $data->{$dist}->{requires} };
}
Tony
Re: Module dependencies
At 14:13 +0100 9/8/03, Michael Stevens wrote: On Mon, Sep 08, 2003 at 01:24:07PM +0100, Shevek wrote: Surely identifying the dependencies of any one module is incomputable in general, and most likely incomputable in the specific cases of many popular modules, especially those with baroque plugin architectures. > Yay, I get to rain on Kake's parade again. Probably you could get most of the data the experimental way - %INC will list things loaded with do, require, or use (see perlvar), so you could 'use' each interesting module on its own and monitor which files get loaded, and generate a suitable graph. Except of course, a lot of modules load other modules depending on parameters passed with -use- (aka the import routine). ;-( Liz
Re: Module dependencies
Shevek said: > On Mon, 8 Sep 2003, Rafael Garcia-Suarez wrote: > >> Shevek wrote: >> > >> > Surely identifying the dependencies of any one module is incomputable >> in >> > general, and most likely incomputable in the specific cases of many >> > popular modules, especially those with baroque plugin architectures. >> >> Of course that depends on whether you want to compute the dependencies >> yourself, or if you rely on metadata such as the Makefile.PLs and >> the META.yml files. > > I believe that there is a sufficient proportion of Makefile.PL files which > compute dependencies rather than using a PREREQ_PM to make this an > unpleasant task. I tend to check for the presence of modules in Makefile.PL and if they are not found give a warning to say that certain functionality is unavailable until they are installed, then check for those modules at runtime if the functions which need them are called. What would be nice would be a way to say here is a list of modules which are nice to have but not required. Then, if running CPAN or CPANPLUS those dependencies could be made into prerequisites or left as nice to have and handled some other way or something. This would probably break any static parser unless there was some convention to follow. Being a heathen, I have no idea how this would interact with Module::Build or META.yml. -- Paul Johnson - [EMAIL PROTECTED] http://www.pjcj.net
Re: Module dependencies
Michael Stevens wrote: > > Probably you could get most of the data the experimental way - %INC will > list things loaded with do, require, or use (see perlvar), so you could > 'use' each interesting module on its own and monitor which files get > loaded, and generate a suitable graph. I think that Module::Info (by Schwern) uses a slightly more sophisticated technique. However, whithout a web connection at the moment, I'm unable to confirm this. So this information is potientially completely worthless.
Re: Module dependencies
On 8 Sep 2003 at 15:29, Elizabeth Mattijsen wrote: > At 14:13 +0100 9/8/03, Michael Stevens wrote: > >Probably you could get most of the data the experimental way - %INC will > >list things loaded with do, require, or use (see perlvar), so you could > >'use' each interesting module on its own and monitor which files get > >loaded, and generate a suitable graph. > > Except of course, a lot of modules load other modules depending on > parameters passed with -use- (aka the import routine). ;-( Or even "require" things at runtime, possibly depending on which subroutine gets called. (For example, subroutine do_foo() might need Acme::Foo but all the others don't, so do_foo() might require() Acme::Foo so that Acme::Foo is a prerequisite only if you actually call do_foo(), but not if you only use the other 42 subroutines.) Cheers, Philip -- Philip Newton <[EMAIL PROTECTED]>
Re: Module dependencies
On Mon, 8 Sep 2003, Kate L Pugh wrote: > Shevek wrote: > >> Surely identifying the dependencies of any one module is incomputable in > >> general, and most likely incomputable in the specific cases of many > >> popular modules, especially those with baroque plugin architectures. > > On Mon 08 Sep 2003, Rafael Garcia-Suarez > <[EMAIL PROTECTED]> wrote: > > Of course that depends on whether you want to compute the dependencies > > yourself, or if you rely on metadata such as the Makefile.PLs and > > the META.yml files. > > Well, I was planning to rely on Module::CPANTS. I'd prefer an extant > imperfect solution to an unimplementable perfect solution, or no solution. It is my general impression of CPAN (and much of the open source world) that there are a great number of solutions to each and every easy problem, and frequently no solution to the harder problems. However... I like the suggestion later in this thread about having a standard way of specifying "optional" modules. I think that such a feature could benefit from considerable architecture support, and would make Makefile.PL (or whatever equivalent) more reliable than some of the home-grown efforts flying around. S. -- Shevekhttp://www.anarres.org/ I am the Borg. http://www.gothnicity.org/
Re: Module dependencies
On Mon 08 Sep 2003, Shevek <[EMAIL PROTECTED]> wrote:
> I like the suggestion later in this thread about having a standard way of
> specifying "optional" modules. I think that such a feature could benefit
> from considerable architecture support, and would make Makefile.PL (or
> whatever equivalent) more reliable than some of the home-grown efforts
> flying around.
Module::Build has this:
recommends
This is just like the "requires" argument, except
that modules listed in this section aren't essen-
tial, just a good idea. We'll just print a
friendly warning if one of these modules aren't
found, but we'll continue running.
So:
use Module::Build;
Module::Build->new
(
module_name => 'Foo::Bar',
requires=> {
'Essential::Module' => 0,
},
recommends => {
'Useful::Nonessential::Module' => 0,
},
)->create_build_script;
Kake
Re: Module dependencies
Je 2003-09-08 15:29:16 +0100, Shevek skribis: > I like the suggestion later in this thread about having a standard way of > specifying "optional" modules. I think that such a feature could benefit > from considerable architecture support, and would make Makefile.PL (or > whatever equivalent) more reliable than some of the home-grown efforts > flying around. Without thinking too hard about the consequences perhaps even having this somehow in the code itself so that in persistent perl environments a list of pre-loadable modules could easily be generated (PerlModule ...) may use Carp; use Maybe qw(Carp); (package Maybe; 1; # would it even have to do anything?) Paul -- Paul Makepeace ... http://paulm.com/ "What is snot? Avatars pick my brian." -- http://paulm.com/toys/surrealism/
Re: Module dependencies
On Mon, 8 Sep 2003, Paul Makepeace wrote:
> Je 2003-09-08 15:29:16 +0100, Shevek skribis:
> > I like the suggestion later in this thread about having a standard way of
> > specifying "optional" modules. I think that such a feature could benefit
> > from considerable architecture support, and would make Makefile.PL (or
> > whatever equivalent) more reliable than some of the home-grown efforts
> > flying around.
>
> Without thinking too hard about the consequences perhaps even having
> this somehow in the code itself so that in persistent perl
> environments a list of pre-loadable modules could easily be generated
> (PerlModule ...)
>
> may use Carp;
> use Maybe qw(Carp);
>
> (package Maybe; 1; # would it even have to do anything?)
It would have to know what symbols Carp exports in order to let our
current translation unit compile correctly. This is .. err... Turing
complete, as usual.
It's raining.
Perhaps (roughly):
use Maybe Carp => qw(cluck croak);
package Maybe;
use vars qw(%EXPORT);
sub import {
my ($class, $package, @export) = @_;
$EXPORT{$_} = $package for @export;
*{"$caller::$_"} = sub { really_import($package, @_) } for @export;
}
sub really_import {
require $EXPORT{shift};
goto something. fuck.
}
S.
--
Shevekhttp://www.anarres.org/
I am the Borg. http://www.gothnicity.org/
Re: Module dependencies
Tony Bowden sent the following bits through the ether: > Obviously depends on Module::CPANTS being correct, but that's an > SEP... I've given up Module::CPANTS to Thomas Klausner. So it's not my P! ;-) May he run with it and do all the things I would do if I didn't have seventeen billion and four things to do. Leon -- Leon Brocard.http://www.astray.com/ scribot.http://www.scribot.com/ ... Any closet is a walk-in closet if you try hard enough
Re: Module dependencies
On 2003.09.08 05:15 Kate L Pugh wrote: I want to find a nice, visual, automatic way of looking at my modules' dependencies. I want a script that I can give the name of a module and optionally a Perl version, and get a recursive list of its dependencies and their dependencies, maybe with highlighting to show which modules have never been in core, which modules are core in my Perl version, etc. Does such a thing or even a start at it exist? I'm sure I remember reading about something like this using Module::CPANTS but I can't find it now. I have Devel::Modlist on CPAN. It's not quite what you seek, but it may be a stepping stone: perl -d:Modlist=stop,cpan script.pl will stop after compilation, but before execution, and print all the loaded modules. It will first check the list against the modlist03.txt file from CPAN and reduce the list so that only the first entry from a given package is printed. I.e., if you used both HTTP::Request and LWP::UserAgent, only one would be printed. Randy -- [EMAIL PROTECTED] http://www.rjray.org http://www.svsm.org Always code as if the guy who ends up maintaining your code will be a violent psychopath who knows where you live. -- Rick Osborne
Re: Module dependencies
Leon Brocard <[EMAIL PROTECTED]> writes: > Tony Bowden sent the following bits through the ether: > >> Obviously depends on Module::CPANTS being correct, but that's an >> SEP... > > I've given up Module::CPANTS to Thomas Klausner. So it's not my P! ;-) > > May he run with it and do all the things I would do if I didn't have > seventeen billion and four things to do. It's always the last four things isn't it?
Re: Module dependencies
On Mon, 8 Sep 2003, Kate L Pugh wrote: > I want to find a nice, visual, automatic way of looking at my modules' > dependencies. I want a script that I can give the name of a module > and optionally a Perl version, and get a recursive list of its > dependencies and their dependencies, maybe with highlighting to show > which modules have never been in core, which modules are core in my > Perl version, etc. > > Does such a thing or even a start at it exist? I'm sure I remember > reading about something like this using Module::CPANTS but I can't > find it now. Autodia does most of what you want. (and it now copes with circular relationships) Any extras I could probably hack in at some point - looking at makefiles, etc and distinguishing core perl and required perl would certainly be useful features. HTH, A. -- Aaron J Trevena - Perl Hacker, Kung Fu Geek, Internet Consultant AutoDia --- Automatic UML and HTML Specifications from Perl, C++ and Any Datasource with a Handler. http://droogs.org/autodia
