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.