Re: [Module-build-general] META.yml extraction on CPAN

[Brian I. <in...@tt...>]

On 14/03/03 16:03 -0600, Ken Williams wrote:
> 
> On Thursday, March 13, 2003, at 07:22  PM, Andreas J. Koenig wrote:
> 
> > Autrijus suggested to me to start extracting the META.yml files as
> > we're doing for the README. So I did. The first yaml file has been
> > extracted for Casey West:
> >
> > -rw-rw-r--    1 root     root          366 Mar 12 21:42 
> > poest-0.20030312.readme
> > -rw-rw-r--    1 root     root          327 Mar 12 21:44 
> > poest-0.20030312.meta
> > -rw-rw-r--    1 root     root        14014 Mar 12 21:46 
> > poest-0.20030312.tar.gz
> 
> Good idea.
> 
> >
> > I realize now that META.yml should contain some protocol.version tag
> > so that the reader knows which fields he can expect.
> 
> Good point - I included the "generated_by" field for this purpose, but 
> an independent protocol field would probably serve the need better.
> 
> > And a spec, what
> > the file contains and a revision history of the spec to know what a
> > specific file contains or should contain depending on
> > protocol.version. And a URL for the spec so that we can point to it.
> >
> > OK, a subset of all this will do.
> 
> I just wrote up http://module-build.sourceforge.net/META-spec.html , 
> see whether that fills the need.  It describes the META.yml files as 
> created by Module::Build version 0.16.  It's a little informal, but I 
> guess we don't need formality yet.
> 
> Probably the first revision we'd make is to add a field like 
> "meta_protocol" for specifying the version of the protocol, like you 
> suggested.

I thought it would be of interest to you to show the meta data schemas
that I am using for FreePAN.org. FreePAN is almost entirely generated
and process driven from meta data.

So far we have two schemas: one for "owner" (same as author in 
Perl), and one for package (same as distribution in Perl). It is
important to note that I am not suggesting that Perl should have all of
the same fields, and the field names do not need to have the same names.
But it would be nice if their was a decent subset of semantic parity.

Here is our owner schema to date (by example):

    owner_id: BrianIngerson
    name: Brian Ingerson
    nickname: ingy
    foreign_id:
      cpan: INGY
      raa: 318
    about:
      Brian Ingerson has been pathologically polluting perl
      since 1998. He has an uncurable case of NIH.
    contact:
      - ingy -at- ttul.org
    package_names:
      - perl/Data-Denter
      - perl/Inline
      - ruby/nonsense
    favorites:
      - ruby/Inline
      - perl/Module-Build
      - perl/HTML-TreeBuilder
      - owner/GisleAas
    donate:
      - http://www.paypal.com/in...@tt...
    links:
      - http://ingerson.com
      - http://www.c2.com
    schema_version: 1

And here is our package schema:
 
    package_name: Inline 
    version: 0.44
    language: perl
    platform: source
    abstract: Write Perl subroutines in other languages
    status: stable
    description:
      Inline is a module that allows you to put source code from other
      programming languages, directly into Perl programs, and just run
      them as normal prgrams, and it all just works.
    modules:
      - Inline
      - Inline::C
      - Inline::MakeMaker
    categories: 
      - Devel/Language
      - Language/C
    requires;
      - perl/Parse-RecDescent: 1.80
    update: Sun Mar 16 01:53:07 PST 2003
    resources: 
      - http://inline.perl.org
      - mailto:in...@pe...
    license: Perl
    owner_id: BrianIngerson
    schema_version: 1

Cheers, Brian