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

Walter Dörwald walter at livinglogic.de
Wed Apr 19 08:22:13 CEST 2006

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. But setuptools will potentially affect anyone that uses third-party modules/packages.

And ctypes, elementtree and pysqlite are mature packages. setuptools isn't even finished yet.

I don't have a problem at all with setuptools going into the standard library. It adds a whole pile of extremely useful functionality (easyinstall, in particular, is something that people have been asking for, constantly, for YEARS). Making it an additional install is just silly

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?

But the alternative to that is complete paralysis - and I can't say that the current state of distutils is at all something to make Python happy.

I started refactoring some of the ugliness out of the internals of distutils last year, but was completely stymied by the demand that no existing setup.py scripts be broken. This means that the people who are experts with the current code are fine, but everyone else has to pay the price.

Servus, Walter

More information about the Python-Dev mailing list