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
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
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
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
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?
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:
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
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.
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
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,
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
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
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
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
14 matches
Mail list logo
