On Feb 26, 2014, at 6:25 PM, Nick Coghlan <ncogh...@gmail.com> wrote:
> > On 27 Feb 2014 08:37, "Vinay Sajip" <vinay_sa...@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
signature.asc
Description: Message signed with OpenPGP using GPGMail
_______________________________________________ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig
