> On Sep 16, 2014, at 7:01 PM, Nick Coghlan <ncogh...@gmail.com> wrote: > > > On 17 Sep 2014 03:02, "Vinay Sajip" <vinay_sa...@yahoo.co.uk > <mailto:vinay_sa...@yahoo.co.uk>> wrote: > > > > From: Paul Moore <p.f.mo...@gmail.com <mailto:p.f.mo...@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
_______________________________________________ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig
