Re^2: Project Metadata Model

[educated_foo]

I don't find this any better than the equivalent Makefile.PL:

# This file provides instructions for packaging.

@prefix : <http://purl.org/NET/cpan-uri/terms#> .

<http://purl.org/NET/cpan-uri/dist/all-your-base-are-belong-to/project
+>
    :perl_version_from _:main ;
    :version_from _:main ;
    :readme_from _:main ;
    :test_requires "Test::More 0.61", "File::Basename", "File::Spec", 
+"Data::Dumper" ;
    :requires "parent", "version 0.77".

_:main <http://www.semanticdesktop.org/ontologies/2007/03/22/nfo#fileN
+ame> "lib/all/your/base/are/belong/to.pm" .

Worse, apparently your packaging script just bundles a bunch of RDF-parsing modules, then calls them from Makefile.PL, so an ordinary CPAN author has to learn your nonstandard RDF system to contribute to your modules. Perl already has at least 3 widely-used formats to describe a module: ExtUtils::MakeMaker, Module::Build, and Module::Install; people should think hard before adding yet another.

[tobyink]

Except that Makefile.PL is an executable file, and if you want the data it contains, you need to run it. Run it and hope that it doesn't hose your system.

Module::Package (which I use) is just a wrapper for Module::Install - which itself is mostly a wrapper for ExtUtils::MakeMaker.

[educated_foo]

It's not that hard to parse a simple Makefile.PL, and a pile of RDF can't represent a complicated one anyways (e.g. can RDF prompt the user for optional deps?). If you want to make things really easy for yourself, use a standard format for your Makefile.PL, which your tools know how to parse. Besides, if you're honestly dealing with modules you trust so little, you should probably audit all the code, including both Makefile.PL and the big pile of stuff in inc/.

In any case, CPAN Testers somehow manages to run oodles of untrusted code without any systems being hosed.

[Xiong]

Perhaps one of the existing formats can be extended to cover the use case?