[Distutils] Q about best practices now (or near future)

Nick Coghlan ncoghlan at gmail.com
Thu Jul 18 00:12:01 CEST 2013

On 18 Jul 2013 06:24, "Oscar Benjamin" <oscar.j.benjamin at gmail.com> wrote:
> On 17 July 2013 17:59, Brett Cannon <brett at python.org> wrote:
> >
> > But it also sounds like that project providing wheel distributions is
> > early to include in the User's Guide.
> There are already many guides showing how to use distutils/setuptools
> to do things the old way. There are also confused bits of
> documentation/guides referring to now obsolete projects that at one
> point were touted as the future. It would be really good to have a
> guide that shows how the new working with wheels and metadata way is
> expected to work from the perspective of end users and package authors
> even if this isn't fully ready yet.
> I've been loosely following the packaging work long enough to see it
> change direction more than once. I still find it hard to see the
> complete picture for how pip, pypi, metadata, setuptools, setup.py,
> setup.json, wheels and sdists are expected to piece together in terms
> of what a package author is expected to do and how it affects end
> users. A guide (instead of a load of PEPs) would be a great way to
> clarify this for me and for the many others who haven't been following
> the progress of this at all.

That's exactly what the packaging guide is for. It just needs volunteers to
help write it.

PEP 426 goes into a lot of detail on the various things that are supported,
but a key thing to keep in mind is that metadata 2.0 is a 3.4.1 time frame
idea, purely for resourcing reasons. The bundling proposed for 3.4 is about
blessing setuptools & pip as the "obvious way to do it". Not the *only* way
to do it (other build systems like d2to1 work, they just need a suitable
setup.py shim, and other installers are possible too), just the obvious way.

For better or for worse, I don't believe we have any more chances to ask
developers to switch to a different front end (heck, quite a few projects
still recommend easy_install or even downloading the sdist and running
setup.py directly). Instead, we need to clearly document the current status
of things, and start working towards *incremental*, *non-disruptive*
changes in the way the back end operates. If we do it right, most users
*shouldn't even notice* when the various tools are updated to produce and
consume metadata 2.0 (which can be distributed in parallel with the
existing metadata formats), unless they decide to use the additional
features the enhanced schema makes possible.

It's good that distil exists as a proof of concept, but the ship has sailed
on the default language level installer: it will be pip.

Updating both pip and setuptools to use distlib as a common backend may be
a good idea in the long run (and probably a better notion than pip growing
a programmatic API of its own), but that's not something I see as urgently


> Oscar
> _______________________________________________
> Distutils-SIG maillist  -  Distutils-SIG at python.org
> http://mail.python.org/mailman/listinfo/distutils-sig
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/distutils-sig/attachments/20130718/9918a7cf/attachment.html>

More information about the Distutils-SIG mailing list