On Thu, Mar 26, 2009 at 12:26 PM, "Martin v. Löwis" <martin at v.loewis.de> wrote: >> Tools like setuptools, zc.buildout, etc. seem great for developers but not >> very good for distributions. At last year's Pycon I think there was >> agreement from the Linux distributors that distutils, etc. just wasn't very >> useful for them. > > I think distutils is different here - it not only helps creating > distributions (i.e. deployable package files), but also allows > direct installation. This, in turn, is used to build the packages > for Linux distributions. E.g. debian/rules often contains a > "setup.py install" call in its build step (and there is even a > CDBS python-distutils.mk fragment) > > In that sense, distutils is for Python what make is for C. It is more like the whole autotools suite (at least for unix), and that's the problem: distutils does everything quite poorly, and once you need to do something that distutils can't do out of the box, you are in a no man's land because distutils is almost impossible to extend (everything is done internally, with no way to recover data short of rewriting everything or monkey patching). To take a recent example, I wanted to add the ability to install a clib extension (pure C, no python API), so that it can be used by other projects: that would take 2 minutes with any build tool out there, but is almost impossible in distutils, unless you rewrite your own build_clib and/or install commands. Even autotools is more enjoyable, which is quite an achievement :) If distutils was split into different modules (one for the build, one for the compiler/platform configuration, one for the installation), which could be extended, tweaked, it would be much better. But the distutils design makes this inherently very difficult (commands). cheers, David
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4