[Python-Dev] need info for externally maintained modules PEP

[Phillip J. Eby]

At 07:56 PM 4/9/2006 +0200, Martin v. Löwis wrote:
>Phillip J. Eby wrote:
> > It would be good if we could have separate setup.py files for "external"
> > libraries, not only because of the ability to get PKG-INFO installed, but
> > also because then OS vendors that split those externals out into separate
> > system packages wouldn't need to jump through as many hoops to build 
> just a
> > single external library like ElementTree or ctypes.
>
>-1. These aren't external libraries; they are part of Python.

They *were* external libraries.  Also, many OS vendors nonetheless split 
the standard library into different system packages, e.g. Debian's 
longstanding tradition of excising the distutils into a separate python-dev 
package.

As much as we might wish that vendors not do these things, they often have 
practical matters of continuity and documentation to deal with; if they 
currently have a "python-ctypes" package, for example, they may wish to 
maintain that even when ctypes is bundled with 2.5.


>  There are
>many build options (such as linking them statically through
>Modules/Setup, or building them as dynamic libraries using
>Modules/Setup, or building them through setup.py); adding more files
>would increase confusion.

I was hoping that we had reached a point where setup.py could simply become 
the One Obvious Way to do it, in which case the One Obvious Way to bundle 
formerly-external libraries would be to bundle their setup scripts.  This 
is particularly helpful for external libraries that still maintain an 
external distribution for older Python versions.


>If you want additional files generated and installed, additional code
>can be put into setup.py to generate them.

Of course it can, and that will certainly solve the issues for packages 
with dependencies on ctypes, ElementTree, and setuptools.  But I was hoping 
for a more modular approach, one that would be more amenable to the needs 
of external library maintainers, and of system packagers who split even the 
core stdlib into multiple packages.  Those packagers will have to figure 
out what parts of the new setup.py to extract and what to keep in order to 
do their splitting.  And the people who develop the libraries will have to 
maintain two unrelated setup.py files.