[Distutils] The PEP 426 defined metadata version will be metadata 3.0

[Donald Stufft]

On Feb 26, 2014, at 6:25 PM, Nick Coghlan <ncoghlan at gmail.com> wrote:

> 
> On 27 Feb 2014 08:37, "Vinay Sajip" <vinay_sajip at yahoo.co.uk> wrote:
> >
> > > If Vinay is happy with that last option for handling the current bdist_wheel misbehaviour
> > > that would mean we could leave the metadata version alone
> >
> > I've changed distlib to ignore pydist.json for wheels with version 1.0, where METADATA is used instead. Note that bdist_wheel also puts a metadata version of 2.0 in the METADATA file.
> >
> > IMO versioning the pydist.json is equivalent to versioning the .dist-info directory - it certainly doesn't seem right to put a metadata version in the directory name itself, as it would effectively be noise almost all of the time.
> >
> > I think it may be premature to promote wheels (as pythonwheels.com is doing with vigour) - nothing wrong with it in principle, of course, it's just the timing which seems wrong. Before such promotion to the community at large, It would seem advisable to get the PyPA house in order by (a) finalising the PEPs which are in limbo because of the focus on getting 3.4 out,
> 
> Wheels work almost as well with setuptools metadata as they will with the initial release of the new metadata spec (because I will be removing the metadata hook extension for the time being - I'm still not convinced that mechanism is a good idea, and I don't think it should delay the other benefits, like providing a format for PyPI to publish dependency metadata directly).
> 
> > (b) ensuring that the 1.1 spec for wheel covers any shortcomings which have been identified in 1.0, as well as more extensive testing for the implementations, and
> 
> The wheel spec needs revision to cover more use cases. That's not a reason to avoid encouraging it's use for the wide range of cases that it already handles.
> 
> However, people do know that I'm not planning to write all these spec updates myself, right? I've claimed 426/440/459, but if you wait for me to write the others as well, we're going to be waiting a long time.
> 

I still need to review the changes to those :(
> I know Donald already has a very early draft of wheel 2.0 in the works, but I'm not aware of anyone that has even started thinking seriously about an sdist 2.0 spec, or an update to the installation database spec - if the latter could include an SQLite based caching mechanism, that would be great, since it lays the foundation for allowing metaimporters to provide installation database entries. And PEP 425 does need an update to cover at least Linux distros (likely based on /etc/os-release).
> 
> 

I have a Wheel 2.0 as well as a new one (or maybe just extending 425) that splits the filename convention out of Wheel.

Could possibly get a dist-info 2.0 in there but I also have two PyPI PEPS and a Python PEP on my TODO list too :/
> Would it help if I created tasks for all the things that still need to be done in the metadata formats repo, and assigned the ones I'm actually working on to myself? That way people could see clearly where we already know work is needed, but nobody has volunteered to do it yet.
> 
> > (c) revisiting accepted PEPs such as 425 to ensure that things are tightened up where needed (for example, there are some problems relating to tags, one of which IIRC Brian Wickman brought up a little while ago - about whether tags should follow the PyPy version numbering rather than the Python language version numbering).
> 
> PEP 425 explicitly covers that. Report bugs against tools that are non-compliant because they expect distutils to automatically do the right thing (when we know it doesn't, especially on Windows and in 2.x).
> 
> Cheers,
> Nick.
> 
> >
> > Regards,
> >
> > Vinay Sajip
> 


-----------------
Donald Stufft
PGP: 0x6E3CBCE93372DCFA // 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/distutils-sig/attachments/20140226/bf725183/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://mail.python.org/pipermail/distutils-sig/attachments/20140226/bf725183/attachment.sig>