Re: Naming advice: parse info out of Build.PL/Makefile.PL
I think the Module::* namespace is the preferred namespace for things that analyze packages. FYI, there already is a Module::MakefilePL::Parse with a similar function, though it doesn't use PPI. (I've not updated it in a long time, since I've put the project that used it on the back burner ;) Perhaps Module::MakefilePL::Parse::PPI and Module::BuildPL::Parse::PPI? Rob
Re: Naming advice: parse info out of Build.PL/Makefile.PL
* Robert Rothenberg [EMAIL PROTECTED] [2006-03-11 16:15]: Perhaps Module::MakefilePL::Parse::PPI and Module::BuildPL::Parse::PPI? Isn’t that backwards? Following the “generic-to-specific” rule, it should be Module::Parse::MakefilePL::PPI, no? Regards, -- Aristotle Pagaltzis // http://plasmasturm.org/
Re: Naming advice: parse info out of Build.PL/Makefile.PL
Chris Dolan writes: I'm going to write a module that uses PPI to parse Build.PL and Makefile.PL files without executing them. The goal of the project is to deduce information like version, dist name, author, abstract, prereqs, etc. from packages that have incomplete or absent META.yml files. Sounds useful. My current ideas for names: PPIx::Buildfile PPIx::BuildPL/PPIx::MakefilePL Module::Info::PPI::Buildfile Module::Info::PPI::BuildPL/Module::Info::MakefilePL Those don't sound sensible to me: it's what your tool does that matters, not which technology it happens to be implemented using. Package::Buildfile Module::Info::Buildfile Module::Info::BuildPL/Module::Info::MakefilePL The latter pair has the advantage of being more intuitive; I'm not sure that I'd immediately realise what a buildfile is without more context. Really this project analyzes packages, not modules, but the Module:: namespace seems to be preferred over Package:: on CPAN. (or am I mistaken?) Namespaces are approximations, not hard contraints. Having the namespaces fit exactly would likely mean either the namespaces' names being unwieldily long or fragmenting each namespace into lots of separate namespaces for each of the niches. If Module:: is what's being used then use it, and don't worry that sometimes packages don't contain any modules. Smylers
Re: Naming advice: parse info out of Build.PL/Makefile.PL
In article [EMAIL PROTECTED], Chris Dolan [EMAIL PROTECTED] wrote: I'm going to write a module that uses PPI to parse Build.PL and Makefile.PL files without executing them. I haven't been following the Module::Build stuff closely, but I've always wondered about these sorts of intricate solutions. Shouldn't it be enough to temporarily replace ExtUtils::Makemaker with something that has the same interface and spits out a Build.PL and a META.yml? I do something similar with Test::Prereq to see what's in PREREQ_PM. Having said that, I'd prefer the PPIx::MakefilePL. Distributions aren't about modules or packages (e.g. I can distribute a script in the same framework).
Re: Naming advice: parse info out of Build.PL/Makefile.PL
On Mar 10, 2006, at 2:45 PM, brian d foy wrote:
I haven't been following the Module::Build stuff closely, but I've
always wondered about these sorts of intricate solutions. Shouldn't it
be enough to temporarily replace ExtUtils::Makemaker with something
that has the same interface and spits out a Build.PL and a META.yml? I
do something similar with Test::Prereq to see what's in PREREQ_PM.
No, because when you run Makefile.PL you only get the *output* of
that program. If it has any non-trivial code, then EU::MM is only
seeing the reduction of that content. For example, this cruddy code
exists in one my own older Makefile.PL files:
open my $fh, 'MANIFEST' || die;
my @exefiles = grep {s/\s.*$//; /^scripts\/.*\.pl)$/} $fh;
close $fh;
...
'EXE_FILES' = [EMAIL PROTECTED],
EU::MM only sees
'EXE_FILES' = ['foo.pl', 'bar.pl', ...],
My proposed module would flag that Makefile.PL as non-trivial and
recommend that the author convert it by hand. I've tried doing this
via regexps in the past, but it's too messy. So this time I'm going
to try with PPI. The idea is to make it NOT intricate if possible.
We'll see. I haven't written the code yet...
Chris
--
Chris Dolan, Software Developer, Clotho Advanced Media Inc.
608-294-7900, fax 294-7025, 1435 E Main St, Madison WI 53703
vCard: http://www.chrisdolan.net/ChrisDolan.vcf
Clotho Advanced Media, Inc. - Creators of MediaLandscape Software
(http://www.media-landscape.com/) and partners in the revolutionary
Croquet project (http://www.opencroquet.org/)
Naming advice: parse info out of Build.PL/Makefile.PL
I'm going to write a module that uses PPI to parse Build.PL and Makefile.PL files without executing them. The goal of the project is to deduce information like version, dist name, author, abstract, prereqs, etc. from (possibly untrusted) packages that have incomplete or absent META.yml files. Clearly, only a subset of Build.PL and Makefile.PL files will be easily digestable, but that's expected. My expectations for the use cases for this module will be: * Simply automatic translation of legacy Makefile.PL files into Build.PL files * Extract info from modules that lack META.yml files * Further indexing of CPAN and for my own Module::License::Report project * Exposing license information for CPAN modules to simply redistribution My current ideas for names: PPIx::Buildfile PPIx::BuildPL/PPIx::MakefilePL Package::Buildfile Module::Info::Buildfile Module::Info::BuildPL/Module::Info::MakefilePL Module::Info::PPI::Buildfile Module::Info::PPI::BuildPL/Module::Info::MakefilePL Really this project analyzes packages, not modules, but the Module:: namespace seems to be preferred over Package:: on CPAN. (or am I mistaken?) Thanks, Chris -- Chris Dolan, Software Developer, Clotho Advanced Media Inc. 608-294-7900, fax 294-7025, 1435 E Main St, Madison WI 53703 vCard: http://www.chrisdolan.net/ChrisDolan.vcf Clotho Advanced Media, Inc. - Creators of MediaLandscape Software (http://www.media-landscape.com/) and partners in the revolutionary Croquet project (http://www.opencroquet.org/)
