[Distutils] build system abstraction PEP, take #2

[Antoine Pitrou]

On Tue, 17 Nov 2015 09:33:56 -0500
Donald Stufft <donald at stufft.io> wrote:
> 
> > On Nov 17, 2015, at 9:27 AM, Antoine Pitrou <solipsis at pitrou.net> wrote:
> > 
> >> 
> >> There are a number of separate subcommands that build systems must support.
> > 
> > I wonder how desirable and viable this all is. Desirable, because you
> > are still asking the build system to appear as setuptools *in some way*.
> > Viable, because pip may some day need to ask more from setuptools and
> > then third-party build tools will have to adapt and implement said
> > command-line options, defeating the "abstraction".
> > 
> > In other words, this PEP seems to be only solving a fraction of the
> > problem.
> 
> Can you explain this? I don’t see how it’s true. We need some way for pip
> to invoke the build system no matter what the build system is. Either that
> API is a Python API or that build system is a CLI based API but either way
> there needs to be some way for that to happen. This PEP chooses (at my
> request) a defined CLI API because it makes the delineation between build
> system and pip cleaner.

I may have misunderstood, it seemed to me that "wheel -d" and "develop"
are simply setuptools commands christened by the PEP.

I tend to think Python APIs are better than CLI APIs, but that probably
doesn't make a lot of difference.  This assumes of course that
potential problems are taken care of (such end-of-line conventions and
character encodings on stdin / stdout :-)).  The one of thing where a
CLI API is clearly inferior is error report, though...

> The whole point of this PEP is that once we have it, we can’t just randomly
> require more from the build tool than what is in the interface defined in
> this PEP. If we need more than we have to write a new PEP that extends the
> old interface with a new feature, but at all times it is built on an
> interface that is standardized via a PEP.

That clears things up, thank you.

Regards

Antoine.