[Distutils] Time for a setuptools_lite??

Robert Collins robertc at robertcollins.net
Wed Oct 21 18:00:03 EDT 2015

On 22 October 2015 at 10:53, Paul Moore <p.f.moore at gmail.com> wrote:
> On 21 October 2015 at 22:25, Antoine Pitrou <solipsis at pitrou.net> wrote:
>> Reading this, the CLI options which have to be implemented are
>> completely tied to setuptools' own view of the world.
>> `--single-version-externally-managed`? `--install-headers`? Why should
>> a random build system care about that gunk? What should it do with it?
> Sorry, maybe I didn't explain properly. That's what you can do right
> now. It's certainly completely tied to setuptools' view of the world,
> because that's what it was written for. But just because we supply
> setuptools' options doesn't mean you have to use them (you can just
> ignore most of the junk).
> Changing pip to work based on a more tool-neutral API is a bigger
> piece of work, which has backward compatibility issues. It's doable,
> but then we're back to the whole process of moving forward with a
> better solution. As I've already said, we have a plan for that, it's
> just happening slowly (apparently too slowly for some people, but
> rather than helping with it they seem happier to propose alternative
> approaches that we've typically considered in the past and discarded,
> but hey, it's their free time and they can spend it how they like...)
>> I think Nathaniel's PEP, for all its shortcomings, looked much saner
>> than that piece of ad-hoc specification (a.k.a. "here's the random set
>> of things we're currently doing, let's make a spec out of it"). This is
>> like the Microsoft OOXML of Python packages distribution.
> Absolutely 100%. That spec is just an attempt to document what's
> there, because people keep saying "why do we have to use setuptools?"
> and the answer is "you don't, you can ignore it as long as you emulate
> this tiny portion of its API (and most of *that* you can ignore)".
> Nathaniel's PEP is much closer to what we need - people coming up with
> a concrete way forward that builds on what we have. And the pushback
> he got was where his proposal didn't take into account issues we knew
> needed solving (and the real-time discussion they had seems to have
> helped bring people's understanding a lot closer together, even though
> progress seems to have stalled since then.

Nathaniel said he was going to follow up on it with the improvements
from the discussion. If he can't, someone else certainly can.


Robert Collins <rbtcollins at hp.com>
Distinguished Technologist
HP Converged Cloud

More information about the Distutils-SIG mailing list