[Distutils] Metadata 2.0: Is there a formal spec for a requirement?

Donald Stufft donald at stufft.io
Wed Sep 17 01:28:46 CEST 2014


> On Sep 16, 2014, at 7:01 PM, Nick Coghlan <ncoghlan at gmail.com> wrote:
> 
> 
> On 17 Sep 2014 03:02, "Vinay Sajip" <vinay_sajip at yahoo.co.uk <mailto:vinay_sajip at yahoo.co.uk>> wrote:
> >
> > From: Paul Moore <p.f.moore at gmail.com <mailto:p.f.moore at gmail.com>>
> >
> >
> > > One thing that might be worth clarifying somewhere/somehow (not
> > > particularly in the specs, though) is where is the best place to find
> > > the "canonical" implementations of the various metadata specs. At one
> > > point, distlib seemed to be taking that role, but I'm not sure it is
> > > any more.
> >
> > 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.
> 
> 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.
> 
> 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.
> 
> 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).
> 
> 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.
> 
> 

Pip does not have runtime dependencies and I am extremely against adding them. They cause nothing but pain for us. Either it’s in the stdlib, it’s vendored, or it’s optional.

This doesn’t include *non runtime* things like what setuptools is now since we’ve vendored pkg_resources. It’s a build system we call out to, not something that pip itself needs to run.

It’s actually been moved into the PyPA github account since I planned on using it in pip.

> > 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)".
> 
> PEP 440 ended up switching to the setuptools forms, to make the pip integration actually practical.
> 
> 

Technically that was a PEP 426 change.
> >
> > 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.
> >
> > 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.
> 
> 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.
> 
> 

Yea, my “problem” with distlib was always that I think Vinay and I wanted two different things from it. I wanted a reference implementation that only came with the PEP standardized pieces, vinay wanted a library that implemented things he could use for distitil.
> >
> > 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?
> 
> Largely reimplementation at this point, except for a couple of PEPs like PEP 470 that aim to clean up certain areas.
> 
> PEP 426 also has a list of other things that will likely need PEPs at some point :)
> 
> 

Probably once the simple API has been cleaned up as well as we can without breaking too much it would make sense to write another PEP just locking the API in place instead of having it’s definition be spread amongst multiple PEPs, the setuptools docs, and the setuptools/pip code bases.

---
Donald Stufft
PGP: 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/20140916/6b386a28/attachment-0001.html>


More information about the Distutils-SIG mailing list