[Python-Dev] need info for externally maintained modules PEP
Phillip J. Eby
pje at telecommunity.com
Sun Apr 9 20:48:47 CEST 2006
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
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.
More information about the Python-Dev