On 13/10/09 13:14, Lennart Regebro wrote:
2009/10/13 Michael Whapples<[email protected]>:
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
_______________________________________________
Distutils-SIG maillist - [email protected]
http://mail.python.org/mailman/listinfo/distutils-sig
