Re: Project Metadata Model

[tobyink]

Does everyone really agree that it's "wise to use no hard tabs in code"? There are quite a few comments at the bottom of that page favouring tabs. See also Why tabs are clearly superior and Why I love having tabs in source code.

I use tabs. I'd compare tabs versus spaces to semantic HTML versus presentational HTML. By using tabs, you can view my source in a text editor with tab stops set to two spaces, four spaces, eight spaces or whatever, and it still looks sensible - I don't enforce my favourite indentation level on you.

Anyway, enough of that, that's not the main point of your post...

Project metadata: what I've been doing lately is to have a directory called meta inside the root directory of the project. This contains zero or more RDF files with project metadata - changelogs, credits, links to the bug tracker, repository, etc.

This can be all in one file, or split up arbitrarily - they are all combined into one in-memory model when they're processed. Currently I tend to use one file for a changelog, one for general project metadata, and a third one for keeping track of dependencies.

My Makefile.PL then assembles this into META.yml and Changes files, figures out the project's licence and creates a LICENSE file too. It does all that at the author side when making a distribution - thus the libraries for metadata management don't need to be installed at the end user's side.

The code for doing all this is on CPAN (of course):

• Module::Install::DOAP - generate META.yml and LICENSE from metadata
• Module::Install::DOAPChangeSets - generate Changes from metadata
• Module::Install::RDF - common bits of above two, factored out into a separate module
• Test::RDF::DOAP::Version - tests that metadata changelog is up to date

Here's an example of a project that uses it: repo and distributed code on CPAN. Notice the size of Makefile.PL? 42 bytes. No metadata there - it's all in the meta directory.

update: here's another (bigger) project using the same metadata system.

[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?

[Anonymous Monk]

What is DOAP, some kind of XML thing?

[tobyink]

DOAP is a vocabulary for describing a software project using RDF.

No XML here.