At 06:46 PM 9/25/2008 +0200, Andreas Jung wrote:
We can not restart with something completely different or new. Such an approach would be totally unacceptable due to the huge amount of existing modules having switched to setuptools. Setuptools or an improved codefork must be the tools for managing distibutions in Python.
Yes and no. Creating a new approach will not cause setuptools to instantly disappear. And assuming the new approach supports only a subset of what setuptools/distutils does, then it should be relatively simple to generate a setuptools-compatible setup.py in distributions created by this other tool, thereby allowing the existing infrastructure to be used.
On the flip side, there is no reason why the new tool(s) cannot *use* setuptools in order to cope with existing packages, as buildout, pyinstaller, and virtualenv already have shown.
At that point, it would remain only to declare distutils and setuptools deprecated and legacy, and provide a clear migration path to the new tool.
The biggest bottlenecks in setuptools development are backward compatibility, testing, and the distutils' excessive flexibility... not to mention the nature of the codebase itself. A new development would allow all of those issues to be addressed at the same time.
_______________________________________________ Distutils-SIG maillist - [email protected] http://mail.python.org/mailman/listinfo/distutils-sig
