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.