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 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). 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
_______________________________________________ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig
