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
