[Distutils] [setuptools] include files and eggs
tseaver at palladion.com
Mon Aug 7 15:36:52 CEST 2006
-----BEGIN PGP SIGNED MESSAGE-----
Ronald Oussoren wrote:
> On 6-aug-2006, at 19:49, Phillip J. Eby wrote:
>> Of course, since it is such a useful and sensible idea, it will of
>> course be incompatible with Debian Python policy.
> This one is worse, it is incompatible with the packaging policy of
> every Linux distribution, header files must be in -devel packages
> obviously :-(. Maybe --single-version-externally-managed should just
> revert to the current "let's install the header in the python headers
> directory" behaviour, that way you won't get the wrath of the Debian
> packagers while "real" eggs behave as they should.
>> Sadly, that isn't a joke, as I'm sure there will be screams of
>> bloody murder regarding the idea of putting headers inside
>> directories inside Python version-specific library directories, not
>> the least since they will want to split such packages into a plain
>> and "devel" version.
> I know, this can be very annoying and seems to be one of the most
> asked questions on this list (or rather, "how do I install distutils
>> There will then be much wailing and gnashing of teeth by people
>> trying to develop SVN-based packages atop Debian, since setuptools
>> will notice the presence of the Debian-installed packages and try
>> to use their (missing) header files when the user attempts to build
>> The Debian team will see nothing wrong with this because obviously
>> the user should've known by osmosis that a -devel package was
>> needed, and... [sigh]
> The end result of which may will be that a meme will spread that says
> you shouldn't use the distributors build of python because that is
That meme is already prevalent in the Zope world: the tradeoffs the
distro authors make when packaging Python (e.g., using UCS4 because it
supposedly makes for a better GUI experience, or putting distutils et.
aliae into a separate, not-installed-by-default package) serve goals
which are not compatible with those of the long-running appserver.
> I don't envy you here, at least some people that try to build
> their own eggs will see this failure and think it's a bug in setuptools.
>> Okay, no point in continuing that rant. Instead, a counter-meme is
>> required, to permit easy education of developers. Maybe something
>> like, "Debian thinks that users aren't developers, so they strip
>> out everything that might be used to develop software. Make sure
>> you have a '-devel' package for *everything* on your system,
>> because otherwise it's impossible to tell what things will be
>> broken when you try to develop software." That has at least some
>> chance of allowing things to work, at the cost of having to be
>> repeated to every single developer that encounters the problem, and
>> for every Python package that might be their point of entry to
>> discovering the problem.
>> Unfortunately, this is a religious issue, which means it is not
>> solvable by merely technical means.
> I'm afraid you're right. What really annoyed me the last time debian
> vs. eggs was discussed here was that some Debian packagers honestly
> believe that they know better than the authors of packages what the
> dependencies of those packages are.
There is a not-quite-overt cultural issue here: if we automate the
production of .deb files using the original authors' specifications,
then we remove the possibility of needing a Debian developer to be the
"maintainer" of said packages.
>> If it were possible to have a mapping from PyPI projects to Debian
>> packages, it would at least be possible in theory for setuptools to
>> notify the user of the missing Debian package. However, Debian
>> policy conflates various meanings of "package" in a way that is
>> utterly incompatible with such a mapping, only manual mapping is
>> possible. Essentially, there would have to be some kind of
>> *manually maintained* global mapping of PyPI project names to
>> Debian package names. If somebody in the Debian community wants to
>> create and maintain the thing, then in theory at least, setuptools
>> could use it to tell the user to install the Debian packages, or
>> invoke the corresponding package installation tools.
> Does debian really split some projects into multiple debian packages
> (excluding -devel variants)? I know they do this for some non-python
> stuff, but haven't noticed this for python software yet. Not that I'm
> likely to notice, the only Debian machine I manage at the moment
> isn't running much python software.
- From a packager's point of view, it might be sensisble, especially for
things like the conditional dependencies called out in setuptools'
"features": GUI support might be optional, for instance.
> Given that at least some Debian developers think setuptools is
> superfluous I wouldn't hold my breath waiting for a volunteer that
> maintains a mapping from PyPI to debian package names.
Maybe the pool is not Debian-developers-who-use-PyPI, but
Tres Seaver +1 202-558-7113 tseaver at palladion.com
Palladion Software "Excellence by Design" http://palladion.com
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v18.104.22.168 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
-----END PGP SIGNATURE-----
More information about the Distutils-SIG