Distribute and setuptools: what are the differences
Hello, I realise I may be starting something I would prefer not to (looking at some of the replies of the announcement of setuptools 0.6c10), so I would like to ask that this tries to stay as a factual thing rather than a "having a go at the other". 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)? It would be nice to have this information as at the moment its a bit unclear what either really are trying to offer over the other. I would like to be able to make a fully informed choice on why use one over the other, I feel at the moment this isn't possible. 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, so not allowing the one which specifically wants setuptools to get the latest setuptools (eg. now or soon it will be setuptools 0.6c10). It is tempting for me to use distutils and 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, but my main concern is my package and if no solution currently can satisfy me it is suitable then unfortunately custom solutions may be the best option for me (I won't support a mess). Michael Whapples
On 2009-10-13, Michael Whapples <mwhapples@aim.com> wrote:
Hello, I realise I may be starting something I would prefer not to (looking at some of the replies of the announcement of setuptools 0.6c10), so I would like to ask that this tries to stay as a factual thing rather than a "having a go at the other".
As it seems that setuptools is not "dead" just possibly a bit slow at being updated,
Setuptools has effectively been dead for a year. Critical patches were not being applied and there was no hope (till a few days ago) of ever getting them fixed. This goes way beyond "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)?
Setuptools being completely dead (till a few days ago), distribute's aim was basically just to have a working setuptools. So: no differences, except that patches have been applied (and iirc one useful non-intrusive addition of being able to upload sphinx docs to pypi).
It would be nice to have this information as at the moment its a bit unclear what either really are trying to offer over the other. I would like to be able to make a fully informed choice on why use one over the other, I feel at the moment this isn't possible.
Technically both are the same (not looking at the bugfixes). The choice is between open source development and project management styles: PJE's setuptools and Tarek-and-a-lot-of-other-people's distribute.
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, so not allowing the one which specifically wants setuptools to get the latest setuptools (eg. now or soon it will be setuptools 0.6c10).
For a globally installed setuptools or distribute: yes, that's a mess. When you use buildout (or pip, apparently) to manage a per-project isolated set of eggs, they will happily coexist (once the 0.6.5 is out with a small fix). So it also depends a bit on the way you set up your project. Reinout -- Reinout van Rees - reinout@vanrees.org - http://reinout.vanrees.org Software developer at http://www.thehealthagency.com "Military engineers build missiles. Civil engineers build targets"
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.
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. 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.
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. -- Lennart Regebro: Python, Zope, Plone, Grok http://regebro.wordpress.com/ +33 661 58 14 64
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
On Tue, Oct 13, 2009 at 02:48:34PM +0100, Michael Whapples wrote: [...]
and I am very much now thinking to avoid setuptools/distribute.
Nothing wrong with that, if you don't need any of the features provided by setuptools/distribute then using them is pointless extra dependency. I've always avoided using them in my packages since I see no convincing benefit compared to downsides, that way users have the choice to use plain distutils or easy_install. And I see not forcing setuptools/distribute on users as a feature. Regards Floris -- Debian GNU/Linux -- The Power of Freedom www.debian.org | www.gnu.org | www.kernel.org
Floris, I think I have come to the same conclusion. There are a couple of features I use from setuptools but I feel it might just be better to produce my own custom code for that. Michael Whapples On -10/01/37 20:59, Floris Bruynooghe wrote:
On Tue, Oct 13, 2009 at 02:48:34PM +0100, Michael Whapples wrote: [...]
and I am very much now thinking to avoid setuptools/distribute.
Nothing wrong with that, if you don't need any of the features provided by setuptools/distribute then using them is pointless extra dependency. I've always avoided using them in my packages since I see no convincing benefit compared to downsides, that way users have the choice to use plain distutils or easy_install. And I see not forcing setuptools/distribute on users as a feature.
Regards Floris
2009/10/13 Michael Whapples <mwhapples@aim.com>:
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)
Because setuptools is used not only when you create packages, but also when you install them, is the main reason. And that means we need to replace setuptools. Again, it's not a choice on the package level, but on the user level. It's like a car. It requires wheels. Which brand you use doesn't matter. But you can't have 8 sets of tires on a 4 wheel car. :)
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.
Nope. It needs to *use* Distribute to install under Python 3. But that is not a problem, as setuptools doens't exist for Python 3, so there is no conflict there. But it would still specify and import setuptools.
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()
Oh, right, don't do that. Does any package do that? Crazy stuff. :-)
If it helps you, it helps. I was more meaning it doesn't help the python community, it doesn't help solve this mess.
I don't think this mess can be solved. We can only walk around it by building something new and better by refactoring setuptools into small pieces. I know some people of the Distribute team has started (tentatively called Distribute2) and PJE has also expressed interest in doing this. If some sort of cooperation can happen there that would be good, if not people will have a choice, and that's also good. In any case Distribute 0.6/setuptools will slowly go out of use. But this is a process that will take years. Unfortunately I don't think a short term solution is realistic.
Anyway I will have to just consider what direction would be most productive for my packages
Neither. You don't need a direction for your packages. If setuptools have a feature you need, use it. If setuptools turns out to have bugs, or you need Python 3 support, then install Distribute. Your package will not notice the difference. I'd like to repeat again, just to make sure that there are no misunderstandings, that this is not about winning, and that there is no competition between setuptools and distribute. Distribute is, as of today, only one thing: setuptools + bugfixes + python 3 support. There is no reason for you to use Distribute unless you need Python 3 support or encounter a setuptools bug (unless you feel like fixing bugs or betatesting Distribute of course). setuptools 0.6c10 will remove most or all of the bug difference, which means there is less reason for people to switch to Distribute. That's a good thing. Distribute doesn't need users. It's users who needs Distribute. That's why it exists. It's driven purely out of necessity, nothing else. -- Lennart Regebro: Python, Zope, Plone, Grok http://regebro.wordpress.com/ +33 661 58 14 64
On Tue, Oct 13, 2009 at 04:26:46PM +0200, Lennart Regebro wrote:
2009/10/13 Michael Whapples <mwhapples@aim.com>:
from ex_setup import use_setuptools use_setuptools()
Oh, right, don't do that. Does any package do that? Crazy stuff. :-)
I'm glad I wasn't the only one thinking that! :-) Floris
On 13/10/2009, at 7:16, Michael Whapples <mwhapples@aim.com> wrote: < lots of rational stuff > +10 d
Hello, I realise I may be starting something I would prefer not to (looking at some of the replies of the announcement of setuptools 0.6c10), so I would like to ask that this tries to stay as a factual thing rather than a "having a go at the other".
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)? It would be nice to have this information as at the moment its a bit unclear what either really are trying to offer over the other. I would like to be able to make a fully informed choice on why use one over the other, I feel at the moment this isn't possible.
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, so not allowing the one which specifically wants setuptools to get the latest setuptools (eg. now or soon it will be setuptools 0.6c10). It is tempting for me to use distutils and 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, but my main concern is my package and if no solution currently can satisfy me it is suitable then unfortunately custom solutions may be the best option for me (I won't support a mess).
Michael Whapples _______________________________________________ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
Michael: Either one will probably work fine. The only differences at this point (setuptools 0.6c10 prerelease and distribute 0.6.4) are which issues have been fixed and how they were fixed. Also they are drop- in replacements for one another, so you can try one and then switch to the other without having to relearn anything. Please report any bugs. Thanks! Regards, Zooko
participants (6)
-
David Arnold -
Floris Bruynooghe -
Lennart Regebro -
Michael Whapples -
Reinout van Rees -
Zooko Wilcox-O'Hearn