On Thu, Mar 26, 2009 at 12:26 PM, "Martin v. Löwis" <mar...@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 _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
