[Python-Dev] setuptools in 2.5.

[Phillip J. Eby]

At 11:08 PM 4/20/2006 -0400, Barry Warsaw wrote:
>Question out of total ignorance: say I get a 3rd party package that has
>a standard distutils setup.py but knows nothing of setuptools.  Say I
>install my own copy of setuptools (or have Python 2.5).  Can that 3rd
>party package still be installed "the setuptools way" without
>modification?

Yes - that's what easy_install does, and that's a big part of what 
setuptools' monkeypatching is for.  The 3rd party package thinks it's 
running with the distutils, but in fact it's running with 
setuptools.  EasyInstall then just asks the package's setup.py to 
"bdist_egg", and once that's done, easy_install just dumps the egg into the 
installation location.  Voila et fini.


>   My guess is that the original packager has to
>do /something/ to utilize setuptools (which is fine really -- I'm mostly
>just curious).

No.  All they have to do is refrain from customizing the distutils beyond 
setuptools' ability to function.  A package that thinks it's subclassing 
the distutils is actually subclassing setuptools, so if they change 
anything too fundamental, the whole house of cards comes down.  For 
example, Twisted assigns distribution.extensions -- an attribute that's 
supposed to be a list of Extension objects or tuples -- to *the number 
1*.  This of course causes setuptools' brain to explode.  :)

Their choice makes sense in distutils terms, because the distutils only 
checks for the truth of this attribute before it gets around to invoking 
the build_ext command -- which they replace.  But setuptools does more 
complex things relating to extensions, because it needs to know how to 
build wrappers for them when they get put into eggs.  So, this is a nice 
example of how complex it can be to extend the distutils in ways that don't 
break random popular packages.

Unfortunately, I can't yet fix this issue with Twisted, because setuptools 
doesn't yet support optional building of extensions.  That's one piece of 
Marc's mxSetup framework that I've been looking to copy or steal once I get 
to really overhauling extension and library building.  My OSAF work 
priorities put that work at a later time than now, however.

Anyway, that's a complete digression from the question you asked.  As long 
as Mailman doesn't depend on building something like Numeric or Twisted, 
you can probably wrap it in easy_install.  If it's not something that uses 
C code, you can just prebuild cross-platform eggs using easy_install.  If 
it uses C code, you'd be able to build it on the target system.

I don't know what Python versions you support, though, and setuptools only 
goes back to Python 2.3.  (Gotta give Google *some* incentive to 
upgrade..  ;)  Although seriously it's because zipimport came in as of 2.3.)