Re: CMSP 19. Make repository resource a hash
On Fri, Oct 9, 2009 at 10:33 PM, Ricardo Signes perl.cpanw...@rjbs.manxome.org wrote: * David Golden xda...@gmail.com [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 02. Formally switch to YAML Tiny
On Fri, Oct 9, 2009 at 10:34 PM, Ricardo Signes perl.cpanw...@rjbs.manxome.org wrote: * David Golden xda...@gmail.com [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 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 xda...@gmail.com 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 03. Deprecate YAML Tiny dialect for JSON
On Fri, Oct 9, 2009 at 10:46 PM, Ricardo Signes perl.cpanw...@rjbs.manxome.org wrote: * David Golden xda...@gmail.com [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 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 26. Specify a DLSIP resource
On Friday 09 Oct 2009 17:07:40 Ricardo Signes wrote: * David Golden xda...@gmail.com [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 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
* Shlomi Fish shlo...@iglu.org.il [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 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 19. Make repository resource a hash
On Friday 09 Oct 2009 15:14:55 Ricardo Signes wrote: * David Golden xda...@gmail.com [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 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 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 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
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 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 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 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 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
On Fri, Oct 9, 2009 at 7:50 AM, David Golden xda...@gmail.com 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
