Re: CMSP 17. Better formalization of license field
On Oct 10, 2009, at 6:32 PM, David Golden wrote:
17.01) Enumerate a list of license strings explicitly in the spec,
rather than by reference to Module::Build::API. Currently, the list
is:
+1
17.02) Make the license field an arrayref rather than a scalar.
Change the definition to have the field be a list of all license which
might apply to the distribution, either as alternatives or for
different subcomponents.
+1 as long as it could also be a scalar, for backcompat and for cases
where there's just one.
17.03) Make the license field optional (defaulting to 'unknown')
-1 I hate when I need to figure out the license for something and
can't find it.
17.04) Instead of license being a list of valid strings, define it as
a Software::License subclass name (which implies an API standad that
can be used to get information about the license like display name and
URL)
-1 Map the strings to subclass names.
17.05) Make the "$meta->{resources}->{license}" field an optional
hashref with name/URL pairs for providing short names and URLs for use
by indexers. (These might get populated by Software::License, of
course.) N.B. This option is probably redundant if 17.02 and 17.04
are adopted.
+1 I like being able to add an explicit URL; that's not covered by
17.02 or 17.04.
Best,
David
Re: CMSP 17. Better formalization of license field
On Fri, Oct 9, 2009 at 7:50 AM, David Golden wrote:
> 17. Better formalization of license field
>
> Proposal:
>
> Replace the list of strings for the "license" field with something
> extensible and unambiguous. (RicardoSignes)
This discussion is going in circles, I think. I'd like to break it
down to a number of specific sub-proposals and get people's reactions
to them individually. These sub-proposals are not all mutually
exclusive, so if you want to react to them as clusters, that's fine,
too.
17.01) Enumerate a list of license strings explicitly in the spec,
rather than by reference to Module::Build::API. Currently, the list
is:
perl
apache
artistic
artistic_2
lgpl
lgpl2
lgpl3
bsd
gpl
gpl2
gpl3
mit
mozilla
open_source
unrestricted
restrictive
unknown
Additional strings (e.g. 'mixed' or additional licenses) could be
added if deemed necessary.
17.02) Make the license field an arrayref rather than a scalar.
Change the definition to have the field be a list of all license which
might apply to the distribution, either as alternatives or for
different subcomponents.
17.03) Make the license field optional (defaulting to 'unknown')
17.04) Instead of license being a list of valid strings, define it as
a Software::License subclass name (which implies an API standad that
can be used to get information about the license like display name and
URL)
17.05) Make the "$meta->{resources}->{license}" field an optional
hashref with name/URL pairs for providing short names and URLs for use
by indexers. (These might get populated by Software::License, of
course.) N.B. This option is probably redundant if 17.02 and 17.04
are adopted.
-- David
Re: CMSP 17. Better formalization of license field
On Oct 10, 2009, at 5:21 PM, Jarkko Hietaniemi wrote: gpl The distribution is licensed under the terms of the GNU General Public License (http://www.opensource.org/licenses/gpl-license.php). What version? There are numerous other ambiguous cases. Likewise, (the same as) "perl" isn't unambiguous enough for the truly/duly paranoid. They want to know what brand of morning cereal Larry was eating when he wrote a particular Perl. license: Lucky Charms David
Re: CMSP 17. Better formalization of license field
Ricardo Signes wrote: > * Zefram [2009-10-10T19:05:20] >> David Golden wrote: >>> Replace the list of strings for the "license" field with something >>> extensible and unambiguous. (RicardoSignes) >> The existing strings *are* unambiguous, and extensible to new >> widely-used licenses. > > Example: > > gpl > > The distribution is licensed under the terms of the GNU General Public > License (http://www.opensource.org/licenses/gpl-license.php). > > What version? > > There are numerous other ambiguous cases. > Likewise, (the same as) "perl" isn't unambiguous enough for the truly/duly paranoid. They want to know what brand of morning cereal Larry was eating when he wrote a particular Perl.
Re: CMSP 17. Better formalization of license field
* Zefram [2009-10-10T19:05:20] > David Golden wrote: > >Replace the list of strings for the "license" field with something > >extensible and unambiguous. (RicardoSignes) > > The existing strings *are* unambiguous, and extensible to new > widely-used licenses. Example: gpl The distribution is licensed under the terms of the GNU General Public License (http://www.opensource.org/licenses/gpl-license.php). What version? There are numerous other ambiguous cases. -- rjbs
Re: CMSP 17. Better formalization of license field
David Golden wrote: >Replace the list of strings for the "license" field with something >extensible and unambiguous. (RicardoSignes) The existing strings *are* unambiguous, and extensible to new widely-used licenses. It seems convenient for this information to be fully machine-understandable, in those cases that are adequately described by a widely-used license. In the unusual cases where no defined keyword suffices, machine readability (beyond recognising that this is the case) is a lot less important. -zefram
Re: CMSP 14. Prerequisites should be mutually exclusive
David Golden wrote: >Modules should only be listed once across all prerequisite categories. Strongly opposed. It's possible for a single module to be required in more than one phase, possibly for independent reasons and possibly with different minimum versions. If the module must be listed only once then the dependencies that an install tool must gather for one of the phases would have to implicitly include all the dependencies listed for the other phase. It would grossly compromise the separation of phases. -zefram
Re: CMSP 13. Add a post_depends set
David Golden wrote: > especially handy for case of circular dependencies, where the A requires > B at runtime, but B requires A at build time. (kentnl) Isn't this just the difference between build_requires and (runtime_)requires? I'm not seeing a difference between the latter and post_requires. -zefram
Re: CMSP 12. Allow Sequences (Arrays) for Prereqs
David Golden wrote: >Right now, to the best of my knowledge, the only benefit of a the magic >"Bundle::" namespace is that its prerequisites can be declared in optimal >installation order. This is a very dubious feature. If it is desirable at all, the mutually-dependent module is the wrong place for this information. -zefram
Re: CMSP 11. OS/arch/platform-specific requirements
David Golden wrote: > os_requires: > Linux: > Linux::Hax: 0 Eww. I'm not totally opposed to having OS-specific prerequisites, but this mechanism is way too specific. This area should be tackled, if at all, by a fully generalised facility for combining prerequisites in ways other than the fixed AND that is currently implicit. I'd quite like to be able to say "must have either Math::BigInt or Math::GMP", for example, if that's what I actually need, rather than having to pick one and require it absolutely. That sort of simple case, with ordinary CPAN modules, seems more useful than anything using the OS type as a prerequisite. -zefram
Re: CMSP 09. Clarify intent of 'recommends' and add 'suggests'
On Sat, Oct 10, 2009 at 5:16 PM, Zefram wrote: > David Golden wrote: >>The 'recommends' flag is not equivalent to Debian recommends. The intent >>should be made clear for authors and the toolchain. If the Debian >>definitions are adopted to better match usage by packagers, a 'suggests' >>field should be added as well. (Adam Kennedy) > > There's too little that we can meaningfully do with optional dependencies, > so introducing another flavour of them wouldn't help. The only > consistently meaningful way to handle recommendations of non-prerequisite > modules is to describe them, and the intended interaction, in the current > module's documentation. The META file is completely the wrong place > for this sort of information. That's not necessarily true. It would be a relatively trivial change to have CPAN/PLUS attempt to install recommends (or suggests/prefers, whatever) -- with or without a prompt -- but not treat their unavailability or test failures as a failure for installing the main module. So this proposal is trying to distinguish (or at least better define) what kind of optional we mean so we know what CPAN/PLUS should do that they don't do today. -- David
Re: CMSP 10. Add a free-text prerequisite field
David Golden wrote: >Add free-text entries that *describe* prerequisites that cannot be >described right now, No thanks. Let's work on ways to machine-readably describe more kinds of prerequisite. C library dependencies are currently a pain to deal with, but their names are reasonably invariant, so we could sensibly list them in META in a formal manner. CPAN installation tools should learn to track this sort of dependency and plug into the OS's packaging mechanism. -zefram
Re: CMSP 09. Clarify intent of 'recommends' and add 'suggests'
David Golden wrote: >The 'recommends' flag is not equivalent to Debian recommends. The intent >should be made clear for authors and the toolchain. If the Debian >definitions are adopted to better match usage by packagers, a 'suggests' >field should be added as well. (Adam Kennedy) There's too little that we can meaningfully do with optional dependencies, so introducing another flavour of them wouldn't help. The only consistently meaningful way to handle recommendations of non-prerequisite modules is to describe them, and the intended interaction, in the current module's documentation. The META file is completely the wrong place for this sort of information. -zefram
CMSP -- summary of discussion so far
Thank you to everyone who has commented so far. I'm very pleased that within 24 hours, we seem to have an emerging consensus (agreeing or opposing) on most proposals. For each proposal listed below, I'm summarizing my take on responses on the mailing list. It's a bit subjective since some responses are "+1 if ...". I've added a bit of commentary as well to help me keep track of the flow of the discussions. #--# Formatting and Schema 01. Update the YAML version declaration Consensus opposed (in favor of 02 instead) 02. Formally switch to "YAML Tiny" Consensus agrees, but with general assent to deprecate YAML for JSON, but specify YAML::Tiny as the legacy format anyway 03. Deprecate YAML Tiny dialect for JSON Consensus agrees. 04. Formalize allowed version number formats Consensus agrees. I note that alpha semantics need to be decided. 05. Schema Consensus is this is "nice to have", but more interest in a validation module over formal schema in the spec. 06. Data structures, not YAML Consensus agrees, though clarifying that only the *spec* should be in Perl data structures. Actual serialization should be described elsewhere. #--# Prerequisites 07. Enhance granularity of prerequisites Consensus agrees. 08. Extensibly Group Prereqs Consensus agrees. 09. Clarify intent of 'recommends' and add 'suggests' No consensus as proposed; discussion of alternative terms 10. Add a free-text prerequisite field No consensus; opposition has stronger voices 11. OS/arch/platform-specific requirements Consensus opposes 12. Allow Sequences (Arrays) for Prereqs No consensus; approval has stronger voices; unresolved details over *usage* of prereqs specified as arrays versus hashes 13. Add a post_depends set No consensus 14. Prerequisites should be mutually exclusive Consensus opposes 15. Add development_requires No strong feeling one way or the other; seen as linked to 08 16. Binary Package Dependencies Consensus is opposed, largely on challenge of doing it "right" #--# Change or clarify existing fields 17. Better formalization of license field No consensus; some discussion of implementation alternatives 18. Make dynamic_config mandatory Consensus is for mandatory dynamic_config OR optional "static_config" with no clear consensus for one or the other 19. Make repository resource a hash Consensus agrees, with debate over keys of repository data structure 20. Make bugtracker resource a hash Consensus agrees 21. Formalize optional_features Consensus agrees that 'optional_features' needs work, with debate over formalizing along the lines of 08 or removal 22. Clarify author field Consensus agrees that clarification is needed; no consensus over what should be done Add new fields 23. Have a "development version" flag Consensus agrees, but issue may be redundant with 24 24. Add a "release_status" field Only a few response and only mild support 25. Controlling test suite runs No consensus; stronger voices opposed 26. Specify a DLSIP resource Consensus opposed, though noting that DSLIP could be generated largely from other META fields 27. Long description Consensus agrees. 28. Short description Consensus opposed. 29. Language Consensus agrees, but with objections raised to 'perl5' as default value 30. Trove-Like Categories Consensus largely opposes as proposed. Some interest in providing free-form keywords instead. 31. Version changes Consensus opposed #--# Other proposals 32. Steal from other package meta specs Consensus opposed (on the grounds that it's not really a proposal) 33. Install Meta files and make them queryable Consensus agrees, with concerns raised over overlap with packfiles 34. Formally reserve keys for private 'in-house' use Consensus agrees, with preference for [xX]- prefix used consistently throughout (and removing case for private keys for resources)
Re: CMSP 07. Enhance granularity of prerequisites
David Golden wrote: >* Should we go all the way towards making prerequisites phase-specific and > have "configure_requires", "build_requires", "test_requires", and > "runtime_requires" Yes please. Currently I put things required for testing into build_requires, but I feel bad about doing it, because testing really is a distinct job from building. Consumers of META information should be expected to merge phase-specific requirements in whatever way is suitable for their workflow; we can't reliably predict what that workflow will be. -zefram
Re: CMSP 06. Data structures, not YAML
Jarkko Hietaniemi wrote: >I really don't think we should have Perl data structures in files >(that means Perl code, right?), because that indicates doing an eval, Not necessarily. Working in *a defined subset of* Perl syntax would mean that readers have both options. Evaling would probably be acceptable in situations where you're installing the module described by the META file, so this could be a convenient option in some small installations. Stats gatherers, who don't want to run code from the module, can use a safe parser as they do now. It so happens that I have a suitable subset of Perl syntax already defined. I needed to implement it a while ago for work purposes, and now it's on CPAN, as Data::Pond. It's similar in spirit to JSON, which of course gives the same kind of parsing choice for the JavaScript language. -zefram
Re: CMSP 19. Make repository resource a hash
On Friday 09 Oct 2009 15:14:55 Ricardo Signes wrote: > * David Golden [2009-10-09T07:51:06] > > > 19. Make repository resource a hash > > > > [Note, a separate "Make repository more machine readable" proposal > > has been merged into this one.] > > Agreed. > Doesn't sound too bad. +1. Regards, Shlomi Fish -- - Shlomi Fish http://www.shlomifish.org/ Original Riddles - http://www.shlomifish.org/puzzles/ Chuck Norris read the entire English Wikipedia in 24 hours. Twice.
Re: CMSP 26. Specify a DLSIP resource
On Saturday 10 Oct 2009 00:14:35 David E. Wheeler wrote: > On Oct 9, 2009, at 8:34 AM, Tim Bunce wrote: > > I think DLSIP codes (which you can blame me for, along with much else > > besides :) should be deprecated in favor of individual metadata > > elements. > > > > It should be possible to generate a DLSIP-like code from the metadata. > > +1 to this suggestion. > +1 too, as I noted earlier. Regards, Shlomi Fish > David > -- - Shlomi Fish http://www.shlomifish.org/ http://www.shlomifish.org/humour/ways_to_do_it.html Chuck Norris read the entire English Wikipedia in 24 hours. Twice.
Re: CMSP 30. Trove-Like Categories
* Shlomi Fish [2009-10-10T06:57:11] > With all due respect to tags, categories still have their advantage, and > should be considered despite their lack of popularity among the latest fads > on the web. One of the reason tags are popular may be due to an easier They've been considered. That's what these emails have been. -- rjbs
Re: CMSP 19. Make repository resource a hash
* David Golden [2009-10-10T07:00:52] > On Fri, Oct 9, 2009 at 10:33 PM, Ricardo Signes > wrote: > > * David Golden [2009-10-09T07:51:06] > >> 19. Make repository resource a hash > > > > Branch available: > > http://github.com/rjbs/cpan-meta-spec/commits/19-repository-hash > > Seems to me that url and type should be mandatory and web should be optional. This won't work in cases where the underlying VCS is private but a browser exists. (Imagine if pre-git we had a p4 history browser for perl.) -- rjbs
Re: CMSP 30. Trove-Like Categories
On Friday 09 Oct 2009 13:55:12 David Golden wrote:
> 30. Trove-Like Categories
>
> Proposal:
>
> Add Freshmeat.net or SourceForge-like trove categories with topics
> programming languages, etc. As opposed to keywords/labels/tags they are a
> nested tree, and will also be limited to a given list. This will help in
> being able to better browse CPAN instead of the old and heavily
> under-maintained long modules list. For example "Programming Language ::
> Lisp", "Intended Audience :: Emacs Users", "Operating System :: GNU",
> "Topic :: Editors".
>
> Shlomi Fish] wrote http://tinyurl.com/ylp4wbz, a functional spec for the
> proposal of enhancing the CPAN classification] which may be read for
> further enlightenment.
>
> Comments:
>
> * Freshmeat no longer has Trove categories, they were replaced by tags.
> --Chorny 15:40, 27 September 2009 (BST)
>
I should note that now that I think about it, we can build categories above
the author keywords by doing something like:
* cat/os/posix
* cat/os/win
* cat/license/modbsd
* cat/license/mit
* cat/topic/ui-toolkit
* cat/topic/template-sys
* cat/audience/end-users
Etc.
The CPANHQ/etc. classifier can pick only the valid m{^cat/} tags, and only the
first ones that match it and use them to classify the module in a SourceForge-
like trove categorisation. So it won't need any additions to the SPEC.
Regards,
Shlomi Fish
--
-
Shlomi Fish http://www.shlomifish.org/
What does "Zionism" mean? - http://shlom.in/def-zionism
Chuck Norris read the entire English Wikipedia in 24 hours. Twice.
Re: CMSP 30. Trove-Like Categories
Excerpts from Shlomi Fish's message of Sat Oct 10 07:05:29 -0400 2009: > if we will allow people to browse the CPAN by > category (like http://dmoz.org/ ), it will be a huge usability improvement. Does anyone actually use dmoz anymore? The last time I stumbled across it was 2003 and it wasn't very helpful then. I don't think it's worth emulating. hdp.
Re: CMSP 26. Specify a DLSIP resource
On Friday 09 Oct 2009 17:07:40 Ricardo Signes wrote: > * David Golden [2009-10-09T07:53:50] > > > 26. Specify a DLSIP resource > > > > Proposal: > > > > DLSIP codes should be specified in META.* as a resource. > > Alternte proposal: > > DLSIP codes should be deleted from the internet and never discussed again > in polite company. > > Opposed. > I agree. Opposed. We may have different values for the DLSIP codes (like license , resources, an array/hash/set for used languages, a field or keywods for the interface style, etc.). But the dlsip field - http://search.cpan.org/dlsip - is a very bad idea. Regards, Shlomi Fish -- - Shlomi Fish http://www.shlomifish.org/ Parody on "The Fountainhead" - http://shlom.in/towtf Chuck Norris read the entire English Wikipedia in 24 hours. Twice.
Re: CMSP 30. Trove-Like Categories
On Friday 09 Oct 2009 16:53:47 Steffen Mueller wrote:
> David Golden wrote:
> > 30. Trove-Like Categories
>
> Opposed. Keywords-set-by-authors don't work very well. We already have
> the underused user-tagging of modules.
>
There are already keywords-set-by-authors. They are under-used but with some
infrastructure changes - like support in CPAN interfaces, and checking for
them in CPANTS, etc. we can make them more popular. As for the user-tagging of
modules - that was only implemented in cpanforum, out of the direct awareness
of people on http://search.cpan.org/ ("Out of sight - out of mind."), and it
has since then broke there, with the maintainer of cpanforum lacking some
resources or other to fix it.
I think we should have them directly on the CPAN interface instead of each
page on s.cpan.o / kobesearch directing to many different resources. That was
one of the aims of http://cpanhq.org/ , which is currently under work by
bricas and other people (including me). Currently the site just shows a
"Coming soon" page, because they are looking for someone to redesign the web-
interface (which is fine, IMO), and don't want to put it there in its current
state. I think one bird in the hand is better than two in the bush, but I have
yet to convince them.
Regards,
Shlomi Fish
--
-
Shlomi Fish http://www.shlomifish.org/
The Case for File Swapping - http://shlom.in/file-swap
Chuck Norris read the entire English Wikipedia in 24 hours. Twice.
Re: CMSP 30. Trove-Like Categories
On Sat, Oct 10, 2009 at 6:57 AM, Shlomi Fish wrote: > One of the reason tags are popular may be due to an easier > implementation and maintenance. +1 -- David
Re: CMSP 03. Deprecate YAML Tiny dialect for JSON
On Fri, Oct 9, 2009 at 10:46 PM, Ricardo Signes wrote: > * David Golden [2009-10-09T07:42:35] >> 03. Deprecate YAML Tiny dialect for JSON > > Branch available: http://github.com/rjbs/cpan-meta-spec/commits/03-json +1 (I guess I just needed to keep reading my email)
Re: CMSP 30. Trove-Like Categories
On Friday 09 Oct 2009 23:06:25 David Golden wrote: > On Fri, Oct 9, 2009 at 7:55 AM, David Golden wrote: > > 30. Trove-Like Categories > > > > Proposal: > > > > Add Freshmeat.net or SourceForge-like trove categories with topics > > programming languages, etc. As opposed to keywords/labels/tags they are > > a nested tree, and will also be limited to a given list. This will help > > in being able to better browse CPAN instead of the old and heavily > > under-maintained long modules list. For example "Programming Language :: > > Lisp", "Intended Audience :: Emacs Users", "Operating System :: GNU", > > "Topic :: Editors". > > > > Shlomi Fish] wrote http://tinyurl.com/ylp4wbz, a functional spec for the > > proposal of enhancing the CPAN classification] which may be read for > > further enlightenment. > > > > Comments: > > > > * Freshmeat no longer has Trove categories, they were replaced by tags. > > --Chorny 15:40, 27 September 2009 (BST) > > -1 for structured categories > > +1 for freeform author keywords > Just a note - I did not intend the categories to replace the author keywords, but rather to complement them. At the moment the categories at: http://search.cpan.org/ are a joke and give a very distorted view of CPAN (I could not get any of my original modules to enter the long modules list, while other people have for more recent submissions), and if we will allow people to browse the CPAN by category (like http://dmoz.org/ ), it will be a huge usability improvement. This is instead of giving only a huge tag cloud which would be hard to find stuff in, and will be more disorganised. Regards, Shlomi Fish -- - Shlomi Fish http://www.shlomifish.org/ Funny Anti-Terrorism Story - http://shlom.in/enemy Chuck Norris read the entire English Wikipedia in 24 hours. Twice.
Re: CMSP 02. Formally switch to "YAML Tiny"
On Fri, Oct 9, 2009 at 10:34 PM, Ricardo Signes wrote: > * David Golden [2009-10-09T07:42:06] >> 02. Formally switch to "YAML Tiny" > > Branch available: http://github.com/rjbs/cpan-meta-spec/commits/02-yamltiny If we only make this change and not JSON, that's fine. I think a longer section will eventually be necessary to explain serialization options (if there are any) and what clients are expected to do wrt to deserialization and validation. David
Re: CMSP 19. Make repository resource a hash
On Fri, Oct 9, 2009 at 10:33 PM, Ricardo Signes wrote: > * David Golden [2009-10-09T07:51:06] >> 19. Make repository resource a hash > > Branch available: > http://github.com/rjbs/cpan-meta-spec/commits/19-repository-hash Seems to me that url and type should be mandatory and web should be optional. -- David
Re: CMSP 29. Language
On Fri, Oct 9, 2009 at 10:32 PM, Ricardo Signes wrote: > * David Golden [2009-10-09T07:54:51] >> 29. Language > > Branch available: http://github.com/rjbs/cpan-meta-spec/commits/29-language Good start. I'd like to see a list of "known" names, even if just "perl5" and "perl6"and some explanation as to why the field exists (i.e. people uploading perl6 modules to CPAN) David
Re: CMSP 30. Trove-Like Categories
Hi all! On Friday 09 Oct 2009 16:34:27 Graham Barr wrote: > On Oct 9, 2009, at 6:55 AM, David Golden wrote: > > 30. Trove-Like Categories > > > > Proposal: > > > > Add Freshmeat.net or SourceForge-like trove categories with topics > > programming languages, etc. As opposed to keywords/labels/tags they > > are a > > nested tree, and will also be limited to a given list. This will > > help in > > being able to better browse CPAN instead of the old and heavily > > under-maintained long modules list. For example "Programming > > Language :: > > Lisp", "Intended Audience :: Emacs Users", "Operating System :: GNU", > > "Topic :: Editors". > > Many things on the web are moving more towards the use of free form > tagging than > lists of specific categories. > > -1 > You did not explain why they are bad. While this may be true, I still think categories have their advantages. For example, they prevent typos in tags, or a proliferation of similar, but non- identical tags. And they also allow for a unique URL to a category as opposed to a hello+goodbye+farewell / hello+farewell+goodbye / goodbye+farewell+hello proliferation. For example, one of the reasons I switched away from Google Reader back to KDE's Akregator was the fact it used tags for classificiation. So every feed was placed in several places in the tree-like display, and applying it to several tags caused it to be placed in two or more different places there. I could nest a tree conclusively. So I left it with disgust, and frankly KDE's akregator is much better. With all due respect to tags, categories still have their advantage, and should be considered despite their lack of popularity among the latest fads on the web. One of the reason tags are popular may be due to an easier implementation and maintenance. In any case, Wikipedia for example, still has user-maintained categories: * http://en.wikipedia.org/wiki/Category:Perl * http://en.wikipedia.org/wiki/Category:Free_software_programmed_in_C * http://en.wikipedia.org/wiki/Category:Cross-platform_software Regards, Shlomi Fish > Graham. > -- - Shlomi Fish http://www.shlomifish.org/ Interview with Ben Collins-Sussman - http://shlom.in/sussman Chuck Norris read the entire English Wikipedia in 24 hours. Twice.
