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

[Matthias Klose]

Phillip J. Eby writes:
> 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!)

The Python policy is just a sub-part of the Debian Policy [1]; the
Debian Policy predates PyPi.  You are missing the existing bits about
i.e. distribution metadata, distributions, etc.
[1] http://www.us.debian.org/doc/debian-policy/

I cannot find the term "project" in the distutils documentation. Any pointers?

So yes, if peak is a rather complex setup, it might be worthful to
have it as an example for a Debian package and to identify omissions
in Debian packaging practices and distutils/setuptools.


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

It is not the goal for Debian to ship every known Python version; we
try to ship a minimal count of Python versions, which is current and
works for most applications. We discourage shipping deliberate
versions of python modules/packages. IIRC, for the past release of
Debian sarge, we had two versions of pygtk and two versions of wxwidgets.
So it seems that it's quiet possible to do that.

I'm not sure what you mean by the generation of distribution metadata
and different dependencies.

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

agreed, but it cannot be as open as the possibilities of
distutils/setuptools are.  Python packages (in the Debian sense) still
have to follow [1] and general decisions made by release management.

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

That naming scheme was used until recently. As already said, it had
several disadvantages for Debian:

 - manual interaction for each new package name entering the Debian archive

 - big bang transitions between unstable and testing releases.

 - higher space requirements for ftp archives, ftp mirrors, local
   installations, more band with usage

 - old packages left after package upgrades

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

Well, let's see what will happen and lets count the accidents then ;)
Many problems that PyPI and setuptools try to solve are well addressed
by existing packaging tools for Linux and *BSD distributions. It would
be nice to see setuptools to use this infrastructure where available.
Linux and *BSD distributions do integrate software well, PyPI and
setuptools might do that job better for Python things, but just for
Python things. I'm sure you can improve things from both sides.

  Matthias