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

[Andrew Straw]

Phillip, thanks for your patient attempts to make this all clear. I
appreciate it. Some more comments at the end...

Phillip J. Eby wrote:
> At 11:51 AM 7/21/2006 -0700, Andrew Straw wrote:
>> I don't see what problem you're trying to solve by having the python
>> version number in the .egg-info/ directory name. :) Is there any
>> Python-version-specific info the in the .egg-info directory?
>
> Yes.
>
>>  How 'bout
>> in the case when it is installed with
>> --single-version-externally-managed command, which what we're talking
>> about with Debian, anyway?
>
> Yes.
>
>
>> Anyhow, this is also creating an issue for me with stdeb because I'm
>> trying to get the generated source packages as close as possible to
>> Debian policy.
>
> Unfortunately, Debian's policy -- especially the idea of mixing paths
> for multiple Python versions -- doesn't mesh well with reality. 
> 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.
>
> (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.)
>
> Anyway, in this case at least, the reason you're running into a
> problem is because there's an inherent problem here, not because
> setuptools is doing something it shouldn't be.
>
OK, I understand your point.

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". Somebody please enlighten me if I'm wrong. I've said
it before and I'll say it again -- I'm no Debian (Python) policy expert.

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