Michael G Schwern wrote:
Elliot just alerted me to this bit of the v2 spec.
http://search.cpan.org/~dagolden/CPAN-Meta-2.101091/lib/CPAN/Meta/Spec.pm#Version_Formats
Dotted-integer versions
"All components after the first are restricted to the range 0 to 999."
Why have a limit on a simple i
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' sugg
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
Ricardo Signes wrote:
* Steffen Mueller [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
Graham Barr wrote:
* David Golden [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
Hans Dieter Pearcey wrote:
Excerpts from David Golden's message of Fri Oct 09 07:56:24 -0400 2009:
33. Install Meta files and make them queryable
Proposal: Using something like .packlist or File::ShareDir, the Meta file
should be installed along with the distribution and Meta tools should allow
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 (
Ricardo Signes wrote:
* David Golden [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 no
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.
Steffen
David Golden wrote:
29. Language
Proposal:
Perl 6 is coming. Some code in Perl 6 is already being uploaded to the
CPAN. A new "language" field is an important part of the structure we need
to allow Perl 6 to reuse the existing CPAN rather than to try to reinvent
the whole thing. My recommenda
Ricardo Signes wrote:
* David Golden [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. 'abstra
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?
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
Ricardo Signes wrote:
* David Golden [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 an
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
David Golden wrote:
23. Have a "development version" flag
* Con: Development version'ness would not be determinable post-installation
AdamKennedy
-1 for this reason. Reinventing packlists and EU::Install* while
retaining backward compatibility seems like a big can of worms that may
grind
David Golden wrote:
22. Clarify author field
Consider that it's currently, practically used as a "contact" field. I
get lots of mail that should have gone to a mailing list instead.
Therefore, I'm for:
- Remove the ambiguous "author" field
- Add "contact" field. Potentially with a type asso
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
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
David Golden wrote:
19. Make repository resource a hash
+1
Steffen
Ricardo Signes wrote:
* David Golden [2009-10-09T07:50:32]
18. Make dynamic_config mandatory
Proposal:
Make the 'dynamic_config' a mandatory field (Dagolden)
* Or rename it to static_config (chorny)
Either one would be good.
+1
Steffen
David Golden wrote:
17. Better formalization of license field
no vote.
Steffen
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,
David Golden wrote:
15. Add development_requires
The development_requires field should specify all prerequisites only needed
during development. For example this could include templating or other
preprocessing modules needed to generate the final source. (Slaven Rezic)
Given proposal 8 (reor
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 t
David Golden wrote:
13. Add a post_depends set
* My main concern with this is that the current model creates a simple
directed graph amenable to recursion, and any circular dependencies
imposed become rather obvious. I worry that post_requires dependencies
will make some of the recursion
David Golden wrote:
12. Allow Sequences (Arrays) for Prereqs
In principle, this should be handled by dependency resolution.
Effectively, being able to nudge things in the right direction seems
useful. Realistically, some people don't get their dependencies right.
Is it good to be able to hid
Ricardo Signes wrote:
* David Golden [2009-10-09T07:47:30]
11. OS/arch/platform-specific requirements
Opposed:
* I think this is going to rapidly approach taking the place of dynamic
configuration, and in a bad way. Save a complete proposal for META 3.0
rjbs 15:31, 28 August 2009 (BST)
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
David Golden wrote:
07. Enhance granularity of prerequisites
+1 in conjunction with proposal 08.
Steffen
David Golden wrote:
08. Extensibly Group Prereqs
+1
I think this is a necessary (if big) departure from the status quo.
Steffen
Ricardo Signes wrote:
* David Golden [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 th
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. ot
Ricardo Signes wrote:
* David Golden [2009-10-09T07:43:00]
04. Formalize allowed version number formats
Proposal:
Formalize the spec for version numbers as "decimal or normalized
dotted-integer (leading "v" and at least 3 components). (Dagolden)
Agree. (Wording should be very clear, with
Ricardo Signes wrote:
* David Golden [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: Y
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::
Hi Ask,
Ask Bjørn Hansen wrote:
On Aug 26, 2009, at 10:27, David Golden wrote:
I still like the ABANDONED author idea though -- no work required!
Do you move the distribution files to the A/AB/ABANDONED/ directory
then? If so, that's work and it'll pollute backpan with duplicates (and
req
Hi Moritz, hi Andreas,
(Andreas J. Koenig) wrote:
On Mon, 24 Aug 2009 09:31:38 +0200, Moritz Lenz said:
>>> 2) The uploaded modules have a flag in their META.yml marking them as
>>> Perl 6. The indexer ignores such modules, so that they don't appear in
>>> modules/02packages.details.txt.gz
Hi Andreas, Hi Gabor,
(Andreas J. Koenig) wrote:
>> On Fri, 24 Oct 2008 15:12:12 +0200, "Gabor Szabo" <[EMAIL PROTECTED]>
>> said:
>
> > Here is the output from installing Spreadsheet-Read-0.29:
> > $ module_version YAML
> > 0.66
> > $ module_version YAML::Tiny
> > 1.32
>
> No
39 matches
Mail list logo
