[Python-Dev] setuptools in 2.5. (original) (raw)

M.-A. Lemburg mal at egenix.com
Thu Apr 20 23:53:48 CEST 2006

Ian Bicking wrote:

Fredrik Lundh wrote:

skip at pobox.com wrote:

Maybe they know something we don't. oh, please. it's not like people like myself and MAL don't know anything about package distribution...

(why is it that people who don't distribute stuff are a lot more im- pressed by a magic tool than people who've spent the last decade distributing stuff ? has it ever occurred to you that we know some- thing that you don't ?) There's many people packaging and distributing code with setuptools, but very few of them are on this list. Setuptools has gotten quite a lot of use and a lot of pushback from people, but only from the people who have been using it. People who have complained about Setuptools without using it have had little influence, because most of their suggestions are only resolvable by having Setuptools simply cease to exist, which is not very constructive.

Ian, this is simply not true.

The folks who have complained had good reasons to do so and most of them have been in the distribution field for a long time.

There have been several attempts to get setuptools back on the track with Python standards, but all requests were ignored. Only after endless discussions, Phillip added some weird --long-option-name-that-no-one-can-remember to the setuptools "install" command that restores the standard distutils behavior which should be the default anyway.

The suggestions that were made were constructive. Just look at the distutils-sig archive. Only very few of the suggestions were taken into account. Instead, setuptools fans insisted on their right to have everything "just work" in their sense of the word.

Most of them probably don't even know what the distutils or Python standards are for installing packages, where the motivation to have zip imports came from and have only ever seen and used the setuptools way.

It's natural to then see any suggestion to change their view on things as being counter-productive or hostile. The people who try to get setuptools back on track receive the same kind of hostility that you perceive to be getting from them. This is the reason I stopped discussing these things on distutils-sig.

The two camps need to come together again, but that will require understanding some of the history and standards that we've had in Python ever since Python packages were introduced. It will also require the setuptools folks to get some feeling of respect for those who have worked in the field for years.

You may not know it, but having worked with distutils for a long time, I have great respect for Phillip's work - it's just that I find some of his design decisions wrong, since they don't follow the standards.

But even then, I've seen Phillip make many changes to Setuptools based on feedback from people who just wanted Setuptools to get out of their way; but again, you have to at least be using it to give this kind of feedback.

And somewhat tangential, but related to much of this discussion: if Phillip had been doing developments for distutils all this time instead of making a package that was separately installable under a different name, Setuptools would never have gotten the use and feedback that is has so far received. We could turn this into a discussion about how to handle updates to the standard library, but given the constraints I think Setuptools was developed in the best way possible. If development had happened here on python-dev and released to the large community only with the next Python release, Setuptools would be far inferior to its current state.

I think that the project would have been even better than it is now, had it started out in a different way, namely Python standards compliant.

But like Anthony said: we're still in alpha, so there's still some hope that we can get those few warts removed from setuptools and a true integration in place for everybody to enjoy.

And now for a little pushback the other way -- as of this January TurboGears has served up 100,000 egg files (I'm not sure what the window for all those downloads is, but it hasn't been very long). Has it occurred to you that they know something you don't about distribution? ElementTree would be among those egg files, so you should also consider how many people haven't asked you about problems related to the installation process.

I wonder why people always seem to imply that installing packages has never worked before there was setuptools.

There's really nothing wrong with the standard distutils two step process:

  1. download and unzip the source file

  2. run "python setup.py install"

I've been publishing the mx Tools since 1997. Back then we only had the old Makefile.pre.in mechanism and still most people managed to get the tools working (step 2 then being: "make -f Makefile.pre.in boot; make; make install") without having to ask for help. Since I've started using distutils in 2001, the number of support questions related to compiling and installing the tools dropped to near zero.

I think this is quite a success story for distutils.

Unfortunately, this fact is rarely mentioned in all these setuptools discussions, probably because it's just not the latest greatest and shiniest tool in the world anymore as it was perceived in the early days.

BTW: thanks to Greg Ward for creating distutils in the first place :-)

-- Marc-Andre Lemburg eGenix.com

Professional Python Services directly from the Source (#1, Apr 20 2006)

Python/Zope Consulting and Support ... http://www.egenix.com/ mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/

::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::

More information about the Python-Dev mailing list