[Python-Dev] need info for externally maintained modules PEP (original) (raw)

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 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.

More information about the Python-Dev mailing list