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

[Nick Coghlan]

On 20 July 2013 01:20, Brett Cannon <brett at python.org> wrote:

> If the long-term plan is to bless setuptools then go for the bundling, but
> if that decision has not been made yet then bundling may be premature if the
> bundling of pip with Python moves forward.

PEP 426 is currently looking at blessing a subset of *setup.py*
commands as an interim build system, without blessing any particular
tool.

At the moment, I don't list any required arguments for the individual
commands, but I'm starting to think that needs to change. It's
probably worth looking at the common subset currently supported by
setuptools and d2to1, and figuring out which can be left out as "you
need to know which build system the project is using and invoke them
appropriately" and which we want to standardise.

Something else I see as potentially getting blessed is "assume
setuptools" as a fallback option for projects that don't publish 2.0+
metadata (part of which will include providing a pre-generated
dist-info directory in the sdist, as well as a way to indicate how to
generate the metadata in a raw source tarball or VCS checkout)

That's why I'm OK with the idea of the pip team *only* supporting
installing from wheels if setuptools isn't installed, and treating
setuptools as an implicit install_requires dependency if it is
necessary to install from a source distribution.

Resolving all of this formally is a ways down the todo list though,
and the problem of source-based (rather than wheel-based) integration
is one of the big reasons I see nailing down the metadata 2.0 spec as
a process that still has several months left to run rather than being
"almost finished". At the moment I *don't* see a good
projects-can-use-any-build-system-they-like story for the path from a
Python project tarball to a built and published Fedora or RHEL RPM,
and that concerns me (since making it practical to almost fully
automate that chain is one of my goals).

If you had asked me a couple of months ago, I would have said I
thought we could get away with deferring the answers to these
questions (and PEP 426 is currently written that way), but I now think
we're better of continuing with the setuptools-compatible metadata
approach for the time being, and taking the time to get metadata 2.0
*right* for both binary and source distribution, rather than having to
follow it up with a metadata 2.1 to fix the source distribution side
of things.

Getting PEP 427 (wheel 1.0) approved reasonable quickly was necessary
to provide a successor to eggs that pip was willing to adopt, but I no
longer think there's the same urgency for the metadata 2.0 standard in
PEP 426 (ever since Daniel realised that wheels could work just as a
well with setuptools compatible metadata as they could with a new
metadata standard).

Cheers,
Nick.

--
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia