[Distutils] [setuptools] include files and eggs

[Tres Seaver]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

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  
> manually?").
> 
>> 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  
>> something.
>>
>> 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  
> broken.

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
PyPI-developers-who-use-Debian.


Tres.
- --
===================================================================
Tres Seaver          +1 202-558-7113          tseaver at palladion.com
Palladion Software   "Excellence by Design"    http://palladion.com
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2.2 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFE10Hz+gerLs4ltQ4RAr0fAJ0fiMvkA2KXefoiJlOwHiI5ki9uQwCgzjsh
gDoKL8kxvJTd1hGJqHT09G4=
=Urpg
-----END PGP SIGNATURE-----