[Python-Dev] setuptools in 2.5.

[M.-A. Lemburg]

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 ! ::::