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

[Matthias Klose]

Phillip J. Eby writes:
> Unfortunately, Debian's policy -- especially the idea of mixing paths for 
> multiple Python versions -- doesn't mesh well with reality.

that's a misunderstading, we don't do that. common files are shipped
in one location outside of sys.path and linked to a version specific
location inside sys.path for every python version.

> Python 
> projects don't always install the same files for a given Python version, or 
> the same content in the same files.  Setuptools is only a relatively minor 
> example of this; other Python projects do far more customization of the 
> install process (by Python version and dependencies) than setuptools does 
> of its own.  Bluntly, mixing Python versions on the same path for 
> *installed* packages (whether installed by the distutils or setuptools) 
> borders on insanity.

again, they are not mixed. I didn't see that many packages with
different files between Python versions. could you give some examples?

> (More precisely, it sounds like exactly the sort of thing to do if one 
> wanted to create all sorts of problems for which one could then claim 
> credit for fixing as part of a "quality assurance" effort, constantly 
> patching upstream packages to work around the problems, thereby cementing 
> in one's own mind the importance of doing QA work to fix those upstream 
> authors' shoddy work that fails to live up to your distribution's "quality" 
> standards.  And yet somehow, nobody will ever seem to notice that it's the 
> policy *itself* that's causing the problems,  because of *course* those 
> upstream developers know *nothing* about quality assurance...  sigh.  But 
> that's a rant for another day.)

I don't see the problem you describe. But anyway, doing QA work in
Debian for python packages (related to the pakage itself) is 

- to move around files into FHS conforming locations in the file
  system (in contrast to the Windows centric view of many upstream
  modules / packages installing a thing in _one_ location) and keep the
  package working. FHS is not just a quality standard for Debian.

- remove included third party modules and depend on the modules
  instead which are shipped in the distribution (removed three copies
  of pytz in the last months). Maybe it's the desire of upstream authors
  to provide a complete one-click-setup lacking a decent package
  management system for other platforms, but it should be an option,
  not the default.

- remove files which do not conform to the Debian Free Software
  Guidelines (DFSG), which would disallow the distribution of an
  upstream package in Debian.

- Fix window'isms like linking extension modules with libpython,
  convert file encodings, etc.

- add exact meta information (dependencies) that allows upgrades, even
  partial ones, between distribution releases. It would be nice to use
  upstream meta information, without relying on a newly invented
  dependency tracking system which doesn't integrate well with
  existing packaging systems. I think the PEP trying to get this
  information into the meta-data was rejected as over-specified.

- split an upstream package into more than one binary package to avoid
  unnecessary installations (i.e. install the python-imaging parts,
  which do not depend on X or Sane).

The policy addresses other (Debian related) things like not
introducing new debian package names for new python versions (because
that requires interaction by FTP adminstrators) and avoiding uploads
for every python package when the python version changes and hindering
the release process for the distribution (forcing big-bang updates
between the unstable and the testing release).

So yes, I don't expect upstream authors to know anything about Debian
QA and to adjust the packaging instead as a package maintainer.
Non-Debian specific changes are usually forwarded to the upstream
authors.  Upstreams aren't a homogenous group, from some authors I get
immediate feedback if I modify something in the package, others don't
see a a need to fix a "python setup.py clean" removing half of the
distributed files which cannot be regenerated.

   Matthias