On 17.02.2013 11:11, Nick Coghlan wrote: > FYI > > > ---------- Forwarded message ---------- > From: Nick Coghlan <ncogh...@gmail.com> > Date: Sun, Feb 17, 2013 at 8:10 PM > Subject: PEP 426 is now the draft spec for distribution metadata 2.0 > To: "DistUtils mailing list\"\"" <distutils-...@python.org> > > > The latest draft of PEP 426 is up at http://www.python.org/dev/peps/pep-0426/ > > Major changes since the last draft: > > 1. Metadata-Version is 2.0 rather than 1.3, and the field now has the > same major.minor semantics as are defined for wheel versions in PEP > 427 (i.e. if a tool sees a major version number it doesn't recognise, > it should give up rather than trying to guess what to do with it, > while it's OK to process a higher minor version) > > 2. The "Private-Version" field is added, and several examples are > given showing how to use it in conjunction with translated public > versions when a project wants to use a version numbering scheme that > the standard installation tools won't understand. > > 3. The environment markers section more clearly covers the need to > handle parentheses (this was mentioned in the text, but not the > pseudo-grammar), and the fields which support those markers have an > explicit cross-reference to that section of the spec. > > 4. Leading/trailing whitespace and date based versioning are > explicitly excluded from valid public versions > > 5. Version compatibility statistics are provided for this PEP relative > to PEP 386 (the analysis script has been added to the PEP repo if > anyone wants to check my numbers) > > 6. I have reclaimed BDFL-Delegate status (with Guido's approval) > > Since getting wheel support into pip no longer depends on this version > of the metadata spec, I plan to leave it open for comment for another > week, and then accept it next weekend if I don't hear any significant > objections.
Overall, I think the meta data for Python packages is getting too complicated. Without a support module in the stdlib implementing the required parsing, evaluation and formatting mechanisms needed to analyze and write the format, I'm -1 on adding yet another format version on top of the stack. At the moment, discussing yet another version update is mostly academic, since not even version 1.2 has been picked up by the tools yet: distutils still writes version 1.1 meta data and doesn't even understand 1.2 meta data. The only tool in wide spread use that understands part of the 1.2 data is setuptools/distribute, but it can only understand the Requires-Dist field of that version of the spec (only because the 1.1 Requires field was deprecated) and interprets a Provides-Extra field which isn't even standard. All other 1.2 fields are ignored. setuptools/distribute still writes 1.1 meta-data. I've never seen environment markers being used or supported in the wild. I'm not against modernizing the format, but given that version 1.2 has been out for around 8 years now, without much following, I think we need to make the implementation bit a requirement before accepting the PEP. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Feb 19 2013) >>> Python Projects, Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope/Plone.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::::: Try our mxODBC.Connect Python Database Interface for free ! :::::: eGenix.com Software, Skills and Services GmbH Pastor-Loeh-Str.48 D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg Registered at Amtsgericht Duesseldorf: HRB 46611 http://www.egenix.com/company/contact/ _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
