[Python-Dev] Raising objections (was: setuptools in the stdlib)

[Phillip J. Eby]

At 08:22 AM 4/19/2006 +0200, Walter Dörwald wrote:
>Anthony Baxter wrote:
>
> > I'm not sure how people would prefer this be handled. I don't think we
> > need to have a PEP for it - I don't see PEPs for ctypes, elementtree,
> > pysqlite or cProfile, either.
>
>If I'm not calling shared libraries from Python I can ignore ctypes. If
>I'm not doing XML, I can ignore elementtree. If I'm not doing SQL I can
>ignore pysqlite and if I'm not interested in profiling I can ignore
>cProfile.

And if you're not using setuptools, or any packages that do, you can ignore 
it as well.


>But setuptools will potentially affect anyone that uses
>third-party modules/packages.

Setuptools already exists, so it already affects "anyone that uses 
third-party modules/packages".  That genie isn't going back in the 
metaphorical bottle.

However, if setuptools is in the stdlib, it means that those people won't 
have to install setuptools *first* in order to use a package that's 
distributed using setuptools.  Thus, having it in the stdlib arguably 
*reduces* the impact of setuptools on such users.


> > Sure, it's possible that some people with extremely complicated
> > distutils scripts may find they need to update them.
>
>Wouldn't I need at least have to change "from distutils.core import
>setup" to "from setuptools import setup"? Or to something like:
>
>try:
>     import ez_setup
>except ImportError:
>     import distutils.core as tools
>else:
>     ez_setup.use_setuptools()
>     import setuptools as tools
>
>for backwards compatibility reasons?

If, and *only* if, you want to use setuptools, or your users hound you 
enough to make you.  :)

Nobody is *forced* to use setuptools for a package they are distributing, 
any more than they are forced to use ctypes.  The "setuptools takes over 
everything" argument is purest FUD and nonsense.  Developers use setuptools 
because they want the features, or because their users want them to.

It's true that sometimes users demand setuptools support, when all they 
really want is the ability to build eggs.  For example, some folks were 
bugging Greg Ewing to add it to Pyrex, and I had to point out that as long 
as Pyrex has a PyPI entry and a vanilla setup.py, there is no need for him 
to start using setuptools.  So he created a PyPI entry, making it now 
possible for easy_install users to do this:

$ python2.5 -m easy_install Pyrex
Searching for Pyrex
Reading http://www.python.org/pypi/Pyrex/
Reading http://www.cosc.canterbury.ac.nz/~greg/python/Pyrex/
Best match: Pyrex 0.9.4
Downloading 
http://www.cosc.canterbury.ac.nz/~greg/python/Pyrex/Pyrex-0.9.4.tar.gz
Processing Pyrex-0.9.4.tar.gz
...
zip_safe flag not set; analyzing archive contents...
...
Adding Pyrex 0.9.4 to easy-install.pth file
Installing pyrexc script to /home/pje/bin

Installed /home/pje/lib/python2.5/site-packages/Pyrex-0.9.4-py2.5.egg
Processing dependencies for Pyrex
$

So, nobody was forced to import setuptools in order to offer any features 
to end users.  Setuptools is perfectly capable of running setup scripts and 
making them into eggs on its own, within reasonable levels of distutils 
customization.