On Tue, 17 Nov 2015 09:33:56 -0500
Donald Stufft
On Nov 17, 2015, at 9:27 AM, Antoine Pitrou
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.