[Python-Dev] setuptools in the stdlib ( r45510 - python/trunk/Lib/pkgutil.py python/trunk/Lib/pydoc.py)

[Phillip J. Eby]

At 11:55 PM 4/18/2006 +0200, Fredrik Lundh wrote:
>who decided that setuptools should be added to 2.5, btw?

Guido proposed it on Python-dev when the 2.5 schedule was first being 
discussed.  I discussed it with him off-list, to ensure that it could be 
done in a way that wouldn't interfere with existing setuptools users or 
affect Python itself in a negative way.  (For example, it needed to be 
upgradeable in the field in case users wanted/needed a later version than 
the one included in 2.5.)

He then mentioned it in his 2.5 slideshow at PyCon.  This is the first 
anyone's objected to it, however, at least that I'm aware of.


>it's still listed under "possible additions" in the release PEP,

I imagine that might be why nobody raised any objections sooner, although I 
understood the possibility to mean "if nobody objects".  :)

I also posted on Python-dev repeatedly in recent weeks, referring to how 
the various PEP 302 fixes and updates would interact with setuptools when 
it got in for 2.5.  Also, Neal emailed me the week before last, asking when 
I would be getting setuptools checked in, and I told him April 17th - i.e., 
yesterday.  So, I was under the impression this was all a done deal.


>and there don't
>seem to be a PEP or any other easily located document that explains exactly
>how it works, what's required from library developers, how it affects existing
>toolchains, etc.

The setuptools manual is currently at:

     http://peak.telecommunity.com/DevCenter/setuptools

pending conversion to the standard Pythondoc format.  I posted earlier 
today asking about how it, and the other related manuals should be included 
in the overall Python documentation structure:

     http://mail.python.org/pipermail/python-dev/2006-April/063846.html

The reST source of these manuals is in trunk/sandbox/setuptools, where it 
has been evolving over the last year.


>   is this really ready for inclusion ?

Please define "ready".  I don't mean that in a flippant way, I just don't 
know what you mean.


>does anyone but Phillip understand how it works ?

Does anybody besides Thomas understand how ctypes works?  ;)

Rhetorical jokes aside, every time I've made a significant change to how 
setuptools works, I've posted it to the distutils-sig -- and usually I make 
proposals in advance to get feedback or stimulate discussion.  I regularly 
post explanations there in response to questions from people who are 
integrating it with system packaging tools, or creating various other 
customizations.  And there are other people on distutils-sig who can answer 
questions about it.  The TurboGears community is proficient enough with it 
that it's only once every few months now that a question gets kicked 
upstairs to me to answer.

A number of people have contributed patches, including Ian Bicking and Tres 
Seaver.  Bob Ippolito was a significant participant in the original design 
and wrote some of the initial code for the runtime.  A *considerable* 
number of distutils-sig participants have had design input, either through 
direct suggestions, or through their giving more use case examples that I 
needed to make "just work".

So, I'm not too pleased by insinuations that setuptools is anything other 
than a Python community project.  But MAL and MvL are the only folks from 
Python-Dev who I've seen over there arguing for changes to setuptools -- 
and I actually made changes based on their input, although they rarely got 
100% of what they asked for.

The --really-long-option MAL is complaining about was put in to provide a 
feature that *he and MvL wanted me to include*; I just don't want that 
behavior to be the default behavior for setuptools.  (And neither do 
package developers who have to support "non-root" users on virtual hosting 
systems, or other environments where system packaging tools aren't available.)

So, it seems to me that MAL claiming that nobody got to participate in the 
design process is rather misleading.  It's like somebody who wanted 
decorators in Python and then gripes about the '@' syntax.  Everybody's got 
to compromise a bit.  I put their feature in months ago, and it is even the 
default when you use --root with install.