Thread: [Module-build-general] META.yml extraction on CPAN
Status: Beta
Brought to you by:
kwilliams
Menu
▾
▴
module-build-general
|
From: <and...@an...> - 2003-03-14 01:23:10
|
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 I realize now that META.yml should contain some protocol.version tag so that the reader knows which fields he can expect. 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. What do we have? What do you suggest? -- andreas |
|
From: Ken W. <ke...@ma...> - 2003-03-14 22:03:54
|
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. -Ken |
|
From: <and...@an...> - 2003-03-16 08:26:09
|
>>>>> On Fri, 14 Mar 2003 16:03:31 -0600, Ken Williams <ke...@ma...> said: > 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. Excellent, thanks! I noticed, the license field is explained by pointing with a hyperlink to search.cpan.org. From there I still had to wade through more clicks until I found the documentation. Can this be changed so that the spec itself is the reference point? For the contents of the license field we have already the "P" in the DSLIP entry in the PAUSE database. There we currently offer: ? unknown a Artistic b BSD d distribution_allowed g GPL l LGPL n no_licence o open-source p Standard-Perl r restricted_distribution And here are the current usage statistics: select statp, count(*) from mods group by statp ; +-------+----------+ | statp | count(*) | +-------+----------+ | ? | 1626 | | a | 79 | | b | 21 | | d | 9 | | g | 77 | | l | 10 | | n | 4 | | o | 33 | | p | 841 | | r | 3 | +-------+----------+ Maybe it would be good to have the same options in META.yml. -- andreas |
|
From: Ken W. <ke...@ma...> - 2003-03-18 17:05:31
|
On Sunday, March 16, 2003, at 02:25 AM, Andreas J. Koenig wrote: > I noticed, the license field is explained by pointing with a hyperlink > to search.cpan.org. From there I still had to wade through more > clicks until I found the documentation. Can this be changed so that > the spec itself is the reference point? Yeah, good idea. > For the contents of the license field we have already the "P" in the > DSLIP entry in the PAUSE database. There we currently offer: > > ? unknown > a Artistic > b BSD > d distribution_allowed > g GPL > l LGPL > n no_licence > o open-source > p Standard-Perl > r restricted_distribution I'll add 'lgpl', 'bsd', 'open_source', and 'unrestricted'. I prefer the name 'unrestricted' to 'distribution_allowed', what do you think? I'm just taking the text descriptions from the PAUSE metadata page, mostly. Where possible, I'm linking to the license text itself too. I haven't added 'no_license', because I'd like to require that all M::B-created distributions have a license. Is this an unreasonable burden? I notice that http://www.cpan.org/modules/00modlist.long.html doesn't contain all the options from PAUSE. -Ken |
|
From: <sc...@po...> - 2003-03-18 20:50:06
|
On Tue, Mar 18, 2003 at 11:05:13AM -0600, Ken Williams wrote:
> I'll add 'lgpl', 'bsd', 'open_source', and 'unrestricted'. I prefer
> the name 'unrestricted' to 'distribution_allowed', what do you think?
> I'm just taking the text descriptions from the PAUSE metadata page,
> mostly. Where possible, I'm linking to the license text itself too.
unrestricted != distribution_allowed
distribution_allowed is "distribution allowed without restrictions".
unrestricted has the problem of not stating *what* is unrestricted.
Use? Distribution? Modification?
distribution_unrestricted (or vice-versa) would be better.
> I haven't added 'no_license', because I'd like to require that all
> M::B-created distributions have a license. Is this an unreasonable
> burden?
IMHO yes. Or at least worth a warning.
While I'm thinking on it... you might want to add:
public_domain
MIT
non_commercial_use (free for non-commercial use)
distribution_restricted (ie. commercial software)
The last one is not for CPAN. Its for Module::Build users who are *not*
uploading their software to CPAN. Internal modules, commercial software,
etc... who want to use Module::Build but are not putting it on CPAN.
There's a more general discussion here about what an author does when
they have a license not on the list. I guess "distribution_restricted"
and "distribution_unrestricted" sort of cover the spectrum, but it would
be nice if there was a forward-compatible path for new licenses to be
added.
When Module::Build is confronted with a license it doesn't understsand it
should warn:
"This module is using the unknown license '$license'"
and -f LICENSE ? "see the LICENSE file for details" :
"read the docs or contact the author for details"
but otherwise let it go. The warning will alert authors to typos, users
to odd licenses and it allows one to use new blessed licenses with older
versions of Module::Build.
|
|
From: Brian I. <in...@tt...> - 2003-03-16 10:04:31
|
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 |
|
From: <sc...@po...> - 2003-03-17 04:39:26
|
On Sun, Mar 16, 2003 at 09:25:16AM +0100, Andreas J. Koenig wrote: > For the contents of the license field we have already the "P" in the > DSLIP entry in the PAUSE database. There we currently offer: > > ? unknown > a Artistic > b BSD > d distribution_allowed > g GPL > l LGPL > n no_licence > o open-source > p Standard-Perl > r restricted_distribution <snip> > Maybe it would be good to have the same options in META.yml. If you mean including the above as valid options, sure. If you mean following it exactly (ie. license => 'p') then no. The more readable long-hand should be used rather than the compressed DSLIP letters. |
|
From: <and...@an...> - 2003-03-17 04:46:25
|
>>>>> On Sun, 16 Mar 2003 20:39:14 -0800, sc...@po... (Michael G. Schwern) said: > On Sun, Mar 16, 2003 at 09:25:16AM +0100, Andreas J. Koenig wrote: >> For the contents of the license field we have already the "P" in the >> DSLIP entry in the PAUSE database. There we currently offer: >> >> ? unknown >> a Artistic >> b BSD >> d distribution_allowed >> g GPL >> l LGPL >> n no_licence >> o open-source >> p Standard-Perl >> r restricted_distribution > <snip> >> Maybe it would be good to have the same options in META.yml. > If you mean including the above as valid options, sure. If you > mean following it exactly (ie. license => 'p') then no. The more > readable long-hand should be used rather than the compressed DSLIP > letters. I meant it the way you agree with. Sorry, I didn't spot this ambiguity when writing. -- andreas |
Thanks for helping keep SourceForge clean.
X