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

[Phillip J. Eby]

At 07:15 PM 4/18/2006 +0200, M.-A. Lemburg wrote:
>Why should a 3rd party extension be hot-fixing the standard
>Python distribution ?

Because setuptools installs things in zip files, and older versions of 
pydoc don't work for packages zip files.


>If you want to provide a hot fix for Python 2.3 and 2.4, you
>should make this a separate install, so that users are aware
>that their Python distribution is about to get modified in ways
>that have nothing to do with setuptools.

Their Python distribution is not "modified" -- new modules are merely 
placed on sys.path ahead of the stdlib.  (Which, I might add, is a 
perfectly normal process in Python -- nothing stops users from installing 
their own version of pydoc or any other module via PYTHONPATH.)

Note also that uninstalling setuptools by removing the .egg file or 
directory will effectively remove the hot fix, since the modules live in 
the .egg, not in the stdlib.


>If an application wants to use setuptools for e.g. plugin
>management, then standard distutils features will get
>replaced by setuptools implementations which are not compatible
>to the standard distutils commands, effectively making it
>impossible to access the original versions.

Please do a little research before you spread FUD.  The 'pkg_resources' 
module is used for runtime plugin management, and it does not monkeypatch 
anything.


>Monkey patching is only a last resort in case nothing
>else works. In this case, it's not needed, since distutils
>provides the interfaces needed to extend its command classes
>via the setup() call.

The monkeypatching is there so that the easy_install command can build eggs 
for packages that use the distutils.  It's also there so that other 
distutils extensions that monkeypatch distutils (and there are a few of 
them out there) will have a better chance of working with setuptools.

I originally took a minimally-invasive approach to setuptools-distutils 
interaction, but it was simply not possible to provide a high-degree of 
backward and "sideward" compatibility without it.  In fact, I seem to 
recall finding some behaviors in some versions of distutils that can't be 
modified without monkeypatching, although the details are escaping me at 
this moment.


> > As for discussion, Guido originally brought up the question here a few
> > months ago, and it's been listed in PEP 356 for a while.  I've also
> > posted things related to the inclusion both here and in distutils-sig.
>
>I know, but the discussions haven't really helped much in
>getting the setuptools design compatible with standard
>distutils.

That's because the job was already done.  :)  The setuptools design bends 
over backwards to be compatible with Python 2.3 and 2.4 versions of 
distutils, not to mention py2exe, Pyrex, and other distutils extensions, 
along with the quirky uses of distutils that exist in dozens of distributed 
Python packages.

However, I think you and I may perhaps have different definitions of 
"compatibility".  Mine is that things "just work" and users don't have to 
do anything special.  For that definition, setuptools is extremely 
compatible with the standard distutils.  In many situations it's more 
compatible than the distutils themselves, in that more things "just work".  ;)