On 24 Mar 2014 10:01, "Paul Moore"
On 23 March 2014 23:13, Nick Coghlan
wrote: Now you begin to see the scope of the problem. It's definitely
solvable, but
means asking a whole pile of "required, recommended or distutils-specific?" questions about the existing distutils and setuptools build system :)
"pip already relies on it" sets the minimum for the "required" category, but there's more to a full build system abstraction than what pip currently supports.
OK, I see now. So the ultimate build system will include pip changes to supply build-time options in an as-yet unspecified manner.
There's certainly no way I can do all of that myself, I don't have remotely the level of experience with complex build requirements. But I can probably take the first steps, and leave it to people with the experience to add to it. No promises on timescales but I'll see what I can do.
One thought. do we want to use a setup.py script as the interface, with all its historical baggage, or would we be better using a new script name as the "official" interface (with pip falling back to equivalent setup.py invocations when that script isn't present, for backward compatibility)?
Step 1 is "What does pip currently expect setup.py to support?" Step 2 is "What other existing features of distutils/setuptools do we think a reasonable replacement for setup.py should support?" (I don't believe distutils2 reached the point of addressing this, but that should still be checked) Step 3 ("what, if anything, should replace the setup.py CLI as the build system abstraction?") really depends on the outcome of steps 1 & 2 - this is more a research/documentation consolidation project at this point than it is a design project. Cheers, Nick.
Paul