Re: Trimming the CPAN - Automatic Purging
Hi Elaine, Elaine Ashton wrote: On Mar 28, 2010, at 12:48 PM, Randy Kobes wrote: Jarkko and I were talking about it this morning - as he's not in favour of pruning - while trying to think of a way around the size problem and he reminded me of the idea that, if I recall correctly was Adreas' suggestion a while back, there be an A, B and C 'PAN' of sorts where you could pull varying degrees of content - sort of CPAN:Mini writ large. I don't think that idea ever got any traction because it wouldn't really solve some of the issues for the major upstream mirrors and the mechanics of deciding where to draw the lines between them. I still think it's a good idea though. This sounds a bit like the CPAN - backpan scheme but with some additional levels? I do very much like Tim's proposal for giving old modules a push to BackPAN since, with proper communication of the changes to the authors along with a way to mark exceptions, this would rid CPAN of a lot of cruft that should be on BackPan anyway. I'm not even going to throw in my considerable weight on this whole debate of pruning*. But if backpan became the official way to access old versions starting from yesterday's, wouldn't that mean: a) That the toolchain would have to be adapted to a tiered infrastructure (think of the indexes...) and more importantly: b) The backpan would have to be mirrored all over the place as well, thus pushing the problem to the next level? Best regards, Steffen * If you must know, I don't like the means but sympathize with the goals. PS: This isn't targeted at Elaine specifically, but can everybody please take a step back and relax? Please be civil.
Re: Perl 6 versus the CPAN
Hi David, hi all, David Golden wrote: Except that we're in feature freeze for Perl 5.12, so that won't actually happen until 5.13. But as soon as Perl 5.12.0 ships, I plan to pull the trigger on JSON and HTTP::Lite and make them CPAN.pm dependencies so we can (a) bootstrap CPAN with HTTP and (b) start consuming JSON metadata (and index) files. Amen to that! Regarding SQLite via DBI indexes: Nice idea *after* bootstrapping. But in practical terms, that's never going to fly. p5p will reject any proposals to include anything like SQLite or DBI in core. That doesn't stand the chance of an ice berg in hell. Don't waste your time musing about it. Going one step away from core-ifying that: Bootstrapping this would make initial CPAN client setup a VERY painful experience and I am still under the impression that we[1] are currently trying to make this a smoother experience. I believe structured ascii (or Unicode) text data with a light-weight parser in core is our best bet. The only thing that worries me about this is memory consumption for large index files. Best regards, Steffen [1] This is a literary we in the sense of: Golden et al. Particularly NOT including myself.
Re: CMSP 01. Update the YAML version declaration
Hi all, David Golden wrote: 01. Update the YAML version declaration Proposal: The version declaration for YAML has not been --- #YAML:1.0 for a long time, update it to the current YAML 1.1 equivalent. I'm opposed on practical grounds, as we want Meta parsing in the Perl core (Parse::CPAN::Meta) and attempts to put a full featured YAML parser in core have been rejected. +1 I think for any YAML-based META files, we need to limit ourselves to the subset of YAML that is supported by Parse::CPAN::Meta for these reasons. But as I said, I think discussion of output format is a broader one that needs to consider all options holistically. Cool. I just learned a new word! Cheers, Steffen
Re: CMSP 02. Formally switch to YAML Tiny
Ricardo Signes wrote: * David Golden xda...@gmail.com [2009-10-09T07:42:06] 02. Formally switch to YAML Tiny Proposal: Change the language referring to YAML to instead refer to YAML Tiny and update the specification URL to point to the YAML Tiny specification. (AdamKennedy) Accept with modification: YAML Tiny should be as the specification for YAML-like META files, which should be deprecated in favor of META files encoded in JSON. Certainly, everyone involved in this is aware of this, but let me state one time for the record YAML::Tiny minus dumping == Parse::CPAN::Meta. This assertion holds now and will in future. For this reason, I am *strongly in favour* of defining the YAML-based META files as using this subset/dialect of YAML. As for adopting JSON as the default format: What's the chances of including a full JSON parser in core? IIRC the main reason against including a full YAML parser in core was that they're all different and likely broken in subtle or not so subtle ways. Certainly, they're all dead-and-wrong or in flux (both of which is bad for perl core). I understand this criterion does not apply to JSON? Cheers, Steffen
Re: CMSP 05. Schema
Graham Barr wrote: On Oct 9, 2009, at 6:43 AM, David Golden wrote: 05. Schema Proposal: The META spec should come along with a formal schema definition. (SlavenRezic) I am not so much concerned about a formal schema. But an official module to validate, or purge bad data, would be great. otherwise users end up having to write very defensive code (ie making sure hash/array references are as expected). being able to validate first will simplify code for many people I think this is a very important point considering that it would probably make sense to have this validation supported in the perl core so CPAN(PLUS) can use it. Including a framework such as Rx in core for this seems unlikely. Including a special purpose module (or extending one like Parse::CPAN::Meta) is likely possible and no big deal. Cheers, Steffen
Re: CMSP 06. Data structures, not YAML
Ricardo Signes wrote: * David Golden xda...@gmail.com [2009-10-09T07:44:43] 06. Data structures, not YAML Proposal: The META spec should be defined in terms of (Perl) data structures, and not in terms of YAML. (Slaven Rezic) Agreed, but the spec should be very clear (perhaps, as said, in an appendix) how the data should be serialized and included in dists. I have no strong feelings about this except for what Ricardo wrote above: The serialization method needs to be prominently featured. Steffen
Re: CMSP 10. Add a free-text prerequisite field
Hans Dieter Pearcey wrote: Excerpts from David Golden's message of Fri Oct 09 07:47:00 -0400 2009: 10. Add a free-text prerequisite field Proposal: Add free-text entries that *describe* prerequisites that cannot be described right now, like prerequisite: a working libexpat, Need a perl with defined-or, Need root access to /media/test. (Tux) Putting human-readable stuff in a file intended primarily for machine-readability seems of minimal use to me. I'm in two minds about this. Such a free form field may be useful if you consider that human-readable information may be generated from the META files. (Take a look at search.cpan.org, for example.) I don't see a good way to fill in the information at build time, though, except maybe parsing it from the POD as with abstracts. Steffen
Re: CMSP 14. Prerequisites should be mutually exclusive
David Golden wrote: 14. Prerequisites should be mutually exclusive * I think this would remove a certain amount of useful flexibility, standard light weight META Object modules could easily automate the production of the merged list. This feels like sacrificing on a fundamental point to make life easier when you don't have tools that haven't been written yet --Adam K -1 What Adam said. Steffen
Re: CMSP 16. Binary Package Dependencies
David Golden wrote: 16. Binary Package Dependencies If we could get this right, I'd give all my votes for this. I know that at least Adam and I had been thinking hard about this kind of thing in a different context a few years back. It's utterly hard to get right if at all possible. Sadly, -1. Steffen
Re: CMSP 19. Make repository resource a hash
David Golden wrote: 19. Make repository resource a hash +1 Steffen
Re: CMSP 20. Make bugtracker resource a hash
Hans Dieter Pearcey wrote: Excerpts from David Golden's message of Fri Oct 09 07:51:29 -0400 2009: 20. Make bugtracker resource a hash Proposal: The bugtracker resource shoudl be made into a hash that defines different types of resources, e.g. web page, email report address, etc. (#toolchain discussion) Agree, given a fixed set of keys. Yep, free-form wouldn't be very useful. Steffen
Re: CMSP 21. Formalize optional_features
David Golden wrote: 21. Formalize optional_features I've had more hassle than luck with optional features, but since some people make valid use of it, I'd be (slightly) against removal. +1 to formalization Steffen
Re: CMSP 23. Have a development version flag
David Golden wrote: 23. Have a development version flag * Con: Development version'ness would not be determinable post-installation AdamKennedy Correction to my earlier reply: If we have the META info available *easily* post installation (cf. 33), my vote becomes a +1. Steffen
Re: CMSP 25. Controlling test suite runs
Ricardo Signes wrote: * David Golden xda...@gmail.com [2009-10-09T07:53:28] 25. Controlling test suite runs Proposal: The META spec should add flags to indicate that distribution's tests may be shuffled or run in parallel. (SlavenRezic) I like the idea in general. I'd just set aside a name for the entry and ask the harness guys for a spec. +1. Smart guy, that rjbs. Reading my thoughts and writing replies for me. Steffen
Re: CMSP 24. Add a release_status field
David Golden wrote: 24. Add a release_status field Obviously supersedes the devel version proposal (23). This would depend on post installation, easy querying of META information (33). Steffen
Re: CMSP 26. Specify a DLSIP resource
Hans Dieter Pearcey wrote: Excerpts from David Golden's message of Fri Oct 09 07:53:50 -0400 2009: 26. Specify a DLSIP resource Proposal: DLSIP codes should be specified in META.* as a resource. My impression of DLSIP is that it's nearly as unused as the modules list. Is this inaccurate? I don't think so. Hence: -1 Steffen
Re: CMSP 28. Short description
Ricardo Signes wrote: * David Golden xda...@gmail.com [2009-10-09T07:54:35] 28. Short description Proposal: Field for short description that can be used in search (with higher priority than long description), when generating README, OS packages or submitting dist to Ohloh, Freshmeat and similar sites. 'abstract' currently is module-specific (for ex. for Shipwright: Best Practical Builder) and would not tell much about module purpose in general. --Chorny 01:15, 28 September 2009 (BST) Opposed. abstract is not module-specific. Most things just use the abstract of the main module in a dist. This is not a needed addition. weakly opposed, too. We should always keep in mind how information ends up in META.XXX. Humans should not have to write META stuff. Therefore, the only moderately sane and established free-form source of information is module POD. Since that's sort-of module-specific already, this would not be a very helpful addition. Steffen
Re: CMSP 27. Long description
Ricardo Signes wrote: * David Golden xda...@gmail.com [2009-10-09T07:54:13] 27. Long description Proposal: Field for long description that can be used in search, when generating README, OS packages or submitting dist to Ohloh, Freshmeat and similar sites. --Chorny 19:40, 21 September 2009 (BST) Sure, why not? Because META should be *generated* from other sources. Where should free-form data come from? Steffen
Re: CMSP 31. Version changes
Hans Dieter Pearcey wrote: Excerpts from David Golden's message of Fri Oct 09 07:55:36 -0400 2009: 31. Version changes Proposal: Description of changes in that versions and tags for changes. Useful for submission to Freshmeat and for quick review of changes. --Chorny 18:51, 30 September 2009 (BST) This seems like getting people to agree on a machine-readable changelog format, which appears only slightly more likely than world peace. Am I misreading it? Apart from my usual complaint about where does the information come from?, this seems possible enough if you leave most of it up to the author: Add a sequence that has a version, an *optional* release date, and (a possibly optional) free-form field of changes. Personally, I'd like to go one step further and make the free form field really an array of free-form fields for individual changes. That offers the opportunity for opposed authors to use a single one of them as a free-form field for all changes. Steffen
Re: CMSP 34. Formally reserve keys for private 'in-house' use
Graham Barr wrote: * David Golden xda...@gmail.com [2009-10-09T07:56:46] 34. Formally reserve keys for private 'in-house' use personally I dislike the case distinction and would rather switch to using x- prefixes which are used in so many other places to mean private extensions +1 Graham. phew - did I get to the end :) +1 Steffen
Re: CMSP 02. Formally switch to YAML Tiny
Ricardo Signes wrote: * Steffen Mueller nj88ud...@sneakemail.com [2009-10-09T10:04:44] As for adopting JSON as the default format: What's the chances of including a full JSON parser in core? I believe they are good. JSON.pm has no weird prereqs, works admirably, and the author has no objections. Cool, then count me in. This increases the coreification chances by a lot. Steffen
