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