On Mon, Mar 25, 2013 at 1:23 PM, Daniel Holth <dho...@gmail.com> wrote: > My vision for the setuptools deprecation process is that distutils > rides into the sunset with it. In this future eventually bugs in > setuptools will be solved by porting setup.py to one of (X, Y, Z) > which haven't necessarily been invented yet.
That would be nice (really!) but what are you proposing replace it for building packages with heavy reliance on C extensions? Because for that one use case (and perhaps that alone) it works "pretty okay" for most cases. I don't want to start seeing an infinite number of ways to configure and build extension modules. The great thing about using distutils (or some variant) for this is that if I had the source for a package I could just `./setup.py build` and it would "just work" for all but the most complex cases (SciPy for example). I don't want to have a situation where some projects are using bento and others are using scons and some are using waf and others are using autoconf, etc, etc. It's fine if a few projects have their own special needs for build toolchains and I've been saying all along that building should be separate from installing, and it should be easier to drop in one's own build system. Another thing that setuptools provides that currently works "pretty well" with extension modules is `./setup.py develop`. It calls `setup.py build_ext --inplace` to make extension modules importable. Any build system for extension modules needs to be able to do something similar to support in-place install functionality like `setup.py develop`, `pip install -e`, etc. Erik _______________________________________________ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
