[Distutils] python version information in .egg-info directory name

[Phillip J. Eby]

At 01:32 PM 7/21/2006 -0700, Andrew Straw wrote:
>Upon re-reading the new Debian python policy, I see that the idea of
>having .py files installed in one tree for multiple python versions is
>optional (albeit "strongly encouraged" as stated at
>http://www.debian.org/doc/packaging-manuals/python-policy/ap-packaging_tools.html).
>So, I can personally continue to ignore this supposedly optional aspect
>of the new Debian Python policy, but I don't know for how long. For
>example, recent discussions on the debian-python list suggest to me that
>the use of this new policy is very strongly encouraged rather than
>merely "optional".

I read the entire policy you linked to, and I don't actually see many problems.

It seems to me that the single largest problem in that policy is that it 
clearly predates the existence of the distutils.  It has no conception of a 
Python *project* or *distribution*, only modules and packages.  It's 
therefore not surprising that it also doesn't encompass such issues as 
distribution metadata, package data, namespace packages, and the like.  It 
also explains why the policy is so out-of-sync with e.g. PyPI.  (I hesitate 
to see what would happen if somebody tries to package any of my Python 
projects such as SymbolType or ProxyTypes for Debian: they all are modules 
in the 'peak' package, but each is distributed as a separate project!)

 From the extremely limited conceptual position that only modules and 
packages exist, it's also impossible to understand how you can have 
different versions of things for different versions of Python, because 
everything is defined in terms of the modules!  However, project 
distributions are merely *composed* of modules, and what modules get 
installed (or what distribution metadata is generated) may depend on the 
Python version.  The same project may also have different dependencies, 
depending on the Python version.

These concepts can't be well-understood from the perspective that only 
modules and packages exist, so until the policy's conceptual underpinning 
is expanded, it's going to continue to be difficult to squeeze square pegs 
into the policy's round holes.


>So, to ask your advice, then, how would _you_ suggest stdeb install
>Python packages using the Debian system? Plain old
>"--single-version-externally-managed" without any .egg-info directory
>renaming? That would be simple enough for me...

That is what I would recommend, yes.  Installed, of course, to the standard 
Python directories, rather than to a shared one, since that would lead to 
conflicts when alternate versions exist.

I don't know enough about Debian to know what it does with package naming, 
but I do know that e.g. NetBSD package naming conventions include the 
Python version for which a project is packaged, such that you could have 
py22-foo, py23-foo, and py24-foo of the same project "foo".  IMO, any other 
way of doing it is an accident waiting to happen...  or else a "job 
security" bonus for the people who write the tools and fix the problems.  I 
guess it's always better to look at it from the bright side.  ;)