[Distutils] [setuptools] include files and eggs

[Phillip J. Eby]

At 01:13 PM 8/7/2006 -0700, Andrew Straw wrote:
>In other words, Debian is a lot of things to a lot of people,
>and some have resulted in decisions that are different from those that
>would have been made if Debian was designed to prioritize Python
>user/developer experiences over other considerations.

That's not a fair spin: the same issues apply to any circumstance where the 
developer of a piece of software has a particular intended configuration 
and provides documentation for that configuration, but Debian chooses to do 
something differently -- *without* providing effective notices of the 
modifications.

By which I mean, when they install part of Python and still call the 
package "Python", it's misleading.  Frankly, it is making me consider 
changing the licenses on my packages to a license that disallows using the 
original package name as part of a modified distribution, in order to 
prevent any possible confusion that users can expect some 
Debian-distributed thing to behave the same way as the original version.


>I have the beginnings of a related, but not identical, mapping at
>http://stdeb.python-hosting.com/wiki/stdeb_all.cfg This is not exactly
>what you describe above, but it's a mapping for use by stdeb
>(setuptools-to-debian-source-package converter) that goes from PyPI
>names (well, the "name" field of calls to setuptools.setup() -- is that
>the PyPI name?)

Yes.


>  to the names of packages created by stdeb and other
>Debian packages required or conflicting.

Right, but as you point out, this is entirely outside the scope of Debian 
proper; they may be .deb's but they're heretical ones.


>stdeb is currently completely non-Debian Python policy compliant. Among
>other things, it bundles a Python package distribution in a single .deb,
>which, as you indicate, is not the Debian Way.

Yep.  The Debian Way, if uniformly applied, would effectively preclude and 
forbid jars and gems as well as eggs.  I'm not sure whether it *actually* 
does, however.


>So, this means that my
>mapping is basically one-to-one, whereas a one-to-many mapping is needed
>to deal with Debian's official packages splitting a single Python
>package distribution into multiple .debs.

It's not even that simple, since Debian's Python policy effectively makes 
namespace packages like zope.*, peak.*, and ll.* impossible.  i.e., they 
want those to be many-to-one, despite it producing nonsensical results.


>  For use by setuptools to
>automatically find and download packages, I can see we'd have to tackle
>this issue, at least. Which might also move stdeb towards producing
>Debian-policy compliant packages.

There are only two ways to fix this:

1. Fix Debian Python policy (which is terribly broken)

2. Create a manual mapping for Debianized packages in order to maintain the 
fiction for as long as possible that the policy isn't actually broken.

People being people, you can probably guess which of these is more likely 
to happen.  :)


>Another issue is making pkg_resources.require() aware of Debian such
>that it can query Debian-installed packages that happen not to be built
>with setuptools.

That's taken care of in Python 2.5, barring any heroic measures (i.e. 
patching the distutils) by Debian developers to prevent it.  Packages built 
by the distutils with Python 2.5 produce an .egg-info file to contain the 
necessary metadata.

Of course, it's possible that Debian's song-and-dance to share source code 
across multiple Python versions will in some way break this support.  If 
that happens, I think the best thing to do would be for some people to 
develop an alternative Debian -platform Python that conforms to Python 
standards rather than Debian ones, and for the Python community at large to 
withdraw support for Debianized Python packages that don't map 1-to-1 with 
PyPI.

I'd call it a fork, except that in this case it's clearly Debian who has 
forked Python, so it would be more of an "unforking".  :)

Actually, it's not even anything as dramatic as all that.  The sanest thing 
to do is probably to work to set up infrastructure to package and 
distribute lots of PyPI projects in .deb form on an automated basis, and 
just ignore Debian Python policy altogether.  Let those who want cake eat 
cake, and spend as much time baking it as they want; meanwhile there will 
be pre-baked bread for the masses, as it were.  easy_deb and stdeb are 
clearly the right thing(s) to do; it's just that it will be a cold day in 
hell before they're considered to comply with Debian policy, so it's wasted 
effort to try.