On January 22, 2016 6:27:08 PM EST, Donald Stufft <don...@stufft.io> wrote: > >> On Jan 22, 2016, at 6:04 PM, Scott Kitterman <deb...@kitterman.com> >wrote: >> >> On Friday, January 22, 2016 05:50:13 PM Donald Stufft wrote: >> ... >>> We already have an option like this, the —root option which will >just append >>> a different prefix to all of the installation paths. So essentially >instead >>> of invoking ``python setup.py install —root /tmp/something/`` which >is what >>> I think you’re doing now, you’d do ``pip install —root >/tmp/something/ >>> —no-deps .`` and it’d just work similarly to what you have now, >except pip >>> would be responsible for interacting with the Python build system. >> ... >> >> Why would pip interacting with the Python build system instead of >setuptools >> be better? >> >> Scott K > >setuptools *is* the build system right now (or distutils if you’re >still using >that). So the benefit to Debian right now would be: We maintain the >distutils/setuptools hacks to make them suck less so you don’t have to! > >Longer term, we want to enable people to go hog wild and invent their >own >build systems instead of trying to do it all one size fits all with >everyone >miserable because it doesn’t solve anyones problems nicely. At that >point the >benefit to Debian becomes that instead of having to implement the >standard >build tool interface that these tools implement (Which will most likely >be >geared towards produces wheels, not towards putting files on disk in an >installed location) Debian can just let us maintain that bit of code >too. > >Of course, if Debian would prefer to interact directly with these >tools, it’s >totally fine to do that. The whole point of us doing this work and >trying to >define formats and APIs and not bless implementations is so anyone who >wants >to can slot in their own tool in the process instead of being forced to >use >some blessed tool.
You probably expected something like this back, but here goes anyway... The Zen of Python says, among other things, "There should be one-- and preferably only one --obvious way to do it". Build systems seem to me like a great place to apply that. Build system proliferation is a nightmare. In the last several months I've gone through roughly all of the several hundred packages in the Debian archive that build (or were packed like they build) compiled code (e.g. python C extensions, library bindings, etc.). I was working on two goals: 1) Making sure they built with python3.5 2) Adding support for building with multiple python3 versions For the former, the issue were sometimes buil system related, but for the latter that was almost always the case. When packages used setup.py (and it made no difference if it was distutills or setuputils) it was virtually always easy. For anything else ranged from moderately complex to not worth the trouble. For the things I need it for in the distro, setup.py (with the changes we've made) works really well. Why do we need a bazillion options for Python build tools? To close with another quote from the Zen, "Special cases aren't special enough to break the rules." Scott K P.S. I worry about having to go through waf again [1]. That was painful. [1] https://lists.debian.org/debian-dak/2012/01/msg00009.html
