On 13/10/09 13:14, Lennart Regebro wrote:
2009/10/13 Michael Whapples<mwhapples@aim.com>:
As it seems that setuptools is not "dead" just possibly a bit slow at being updated, could I ask what are the aims of the various projects setuptools and distribute (please try and keep this information restricted to your project and what it aims to do)?
Distribute is created as a response to setuptools not getting the maintenance it deserves. It provides various bugfixes that has been known in setuptools for a long time but not solved. It also nowadays provides Python 3 support. Thanks for that, now it would be nice to hear from P.J. Eby on what setuptools aims to do and why distribute needed to be a fork rather than people added to the development team (what was it in the distribute's teams view that made them unacceptable for setuptools).
I have to say from my view (as a developer of my own packages only using setuptools/distribute to help package my packages) that it currently looks a horrible mess, distribute tries to replace setuptools and does it in such a way that any package which specifically wants setuptools has to use distribute if another package wants it
Distribute is a fork and a complete replacement of setuptools. Hence you can only have one installed in each environment at once. Yes it's a mess. May be there's certain reasons why setuptools and distribute couldn't be designed to coexist on a system (eg. may be its something to do with how they manage the package environment and include packages in eggs), but it would be nice for them to coexist. I am looking at cython/pyrex here. As I understand it cython forked from pyrex and aims to add extra features (eg. cython gives python3 support, cython has some extra ways of specifying for loops, etc), but as I understand it there is no packaging conflict between cython and pyrex and so both may be installed at the same time and not interfere with the other.
There really is not many reasons for any package to require distribute over setuptools. It's not a package choice, it's a user-choice. I sort of understand that but not fully. A package may need to specify distribute if it wants to be python3 compatible. The only way I can get what you say to work in my mind is not to use the automatic install of setuptools/distribute (IE. not to use distribute_setup.py or ez_setup.py in my setup.py script, I mean those lines: from ex_setup import use_setuptools use_setuptools() ). Are you saying/would you advise not to do this automatic install of setuptools/distribute?
create my own custom code to give the features I currently really use from setuptools/distribute until this "mess" has been cleaned up.
I know this idea of going a custom route doesn't really help things
If it helps you, it helps. I was more meaning it doesn't help the python community, it doesn't help solve this mess. Also in a way it doesn't help me as much as I might like as it will take some of my time, time which may be better spent on the package I am developing (the work I may have specific skills in).
Anyway I will have to just consider what direction would be most productive for my packages, having seen some of the recent messages I am quite strongly of the view let a new default (although setuptools has always been a third party package, it was a fairly obvious and fairly popular choice in the past, so as good as default) win out. One final thing, in a different thread http://mail.python.org/pipermail/distutils-sig/2009-October/013845.html, it was said "What would newcomers think", well I am not new to python but only recently joined this list to ask about certain things with distribute and I am very much now thinking to avoid setuptools/distribute. Michael Whapples