<p dir="ltr"><br>
On 17 Sep 2014 03:02, "Vinay Sajip" <<a href="mailto:vinay_sajip@yahoo.co.uk">vinay_sajip@yahoo.co.uk</a>> wrote:<br>
><br>
> From: Paul Moore <<a href="mailto:p.f.moore@gmail.com">p.f.moore@gmail.com</a>><br>
><br>
><br>
> > One thing that might be worth clarifying somewhere/somehow (not<br>
> > particularly in the specs, though) is where is the best place to find<br>
> > the "canonical" implementations of the various metadata specs. At one<br>
> > point, distlib seemed to be taking that role, but I'm not sure it is<br>
> > any more.<br>
><br>
> That's more to do with the preferences of, and choices made by, other people. I don't know who decides what's "canonical" (I suppose Nick, naturally, but I'm not sure if it's *only* Nick) or what criteria they would use, but I've aimed distlib to implement the various PEPs in their various states of completion.</p>
<p dir="ltr">My current hope is that we'll end up with a situation where packaging is the minimalist reference implementation that provides the bare minimum amount of functionality necessary to work with versions (including the installation database) at runtime, while distlib becomes the more feature complete library you'd want on a build system. Think pkg_resources vs setuptools, but without the tight coupling that exists in the status quo.</p>
<p dir="ltr">Someone using packaging would also *only* get features from approved PEPs, freeing distlib as a vector for publishing draft proposals in a way that folks can more easily experiment with and provide feedback on.</p>
<p dir="ltr">Eventually, I believe we should also officially make the "packaging" module a *public* dependency of pip, and update the bundling into CPython accordingly. By default, you would get "pip" and "packaging", with "pip install setuptools" only triggering if you needed to build from source (and no other build dependencies were specified).</p>
<p dir="ltr">If that long term approach sounds reasonable to folks, we should probably promote packaging from Donald's personal repo, include it in the PyPA project list and tweak the description of distlib accordingly.</p>
<p dir="ltr">> Although I have been less active of late than I have previously, that's just down to my current workload: I'm busy with consultancy work :-) Note that I have recently updated distlib to reflect changes in PEP 440, though this functionality has not been officially released (it's available in the public repos, though). On requirements, distlib supports both the setuptools forms "foo>=X.Y" and the PEP forms such as "foo (~ X.Y)".</p>
<p dir="ltr">PEP 440 ended up switching to the setuptools forms, to make the pip integration actually practical.</p>
<p dir="ltr">><br>
> Generally, distlib and distil work well enough [for my needs] for the most part. Where distributions uses custom code in setup.py or extends distutils/setuptools command classes, I use "distil pip" to convert sdists to wheels, or "distil package" to convert .exe installers (like those on Christoph Golhke's site) to wheels. When you pin your dependencies, you don't have to do this dance too often.<br>
><br>
> I feel I'm fairly responsive when issues are raised against either distlib or distil. I'm always open to feedback, try to keep the docs up to date, etc. The coverage docs are a little out of date, and coveralls is on my todo list. Not sure what more would be expected from a canonical implementation, other than an official blessing.</p>
<p dir="ltr">A reference implementation needs *less*, rather than more. However, I've come to realise we want both - the minimalist reference implementation, and the broader platform that includes more scope for experimenting with draft standards.</p>
<p dir="ltr">><br>
> While on the topic of specs, I'm curious to know what the specification status is for other elements in the packaging landscape, such as Warehouse or Twine - are there any PEPs specifying anything new that they do over existing PyPI/distutils, or is there nothing new over and above existing code other than (no doubt improved) reimplementation of existing functionality?</p>
<p dir="ltr">Largely reimplementation at this point, except for a couple of PEPs like PEP 470 that aim to clean up certain areas.</p>
<p dir="ltr">PEP 426 also has a list of other things that will likely need PEPs at some point :)</p>
<p dir="ltr">Cheers,<br>
Nick.</p>
<p dir="ltr">><br>
> Regards,<br>
><br>
> Vinay Sajip<br>
</p>