On 06/21/2012 12:26 PM, PJ Eby wrote:
On Thu, Jun 21, 2012 at 11:50 AM, Chris McDonough <chr...@plope.com <mailto:chr...@plope.com>> wrote:On 06/21/2012 11:37 AM, PJ Eby wrote: On Jun 21, 2012 11:02 AM, "Zooko Wilcox-O'Hearn" <zo...@zooko.com <mailto:zo...@zooko.com> <mailto:zo...@zooko.com <mailto:zo...@zooko.com>>> wrote: > > Philip J. Eby provisionally approved of one of the patches, except for > some specific requirement that I didn't really understand how to fix > and that now I don't exactly remember: > > http://mail.python.org/__pipermail/distutils-sig/2009-__January/010880.html <http://mail.python.org/pipermail/distutils-sig/2009-January/010880.html> > I don't remember either; I just reviewed the patch and discussion, and I'm not finding what the holdup was, exactly. Looking at it now, it looks to me like a good idea... oh wait, *now* I remember the problem, or at least, what needs reviewing. Basically, the challenge is that it doesn't allow an .egg in a PYTHONPATH directory to take precedence over that *specific* PYTHONPATH directory. With the perspective of hindsight, this was purely a transitional concern, since it only *really* mattered for site-packages; anyplace else you could just delete the legacy package if it was a problem. (And your patch works fine for that case.) However, for setuptools as it was when you proposed this, it was a potential backwards-compatibility problem. My best guess is that I was considering the approach for 0.7... which never got any serious development time. (It may be too late to fix the issue, in more than one sense. Even if the problem ceased to be a problem today, nobody's going to re-evaluate their position on setuptools, especially if their position wasn't even based on a personal experience with the issue.) A minor backwards incompat here to fix that issue would be appropriate, if only to be able to say "hey, that issue no longer exists" to folks who condemn the entire ecosystem based on that bug. At least, that is, if there will be another release of setuptools. Is that likely? Yes. At the very least, there will be updated development snapshots (which are what buildout uses anyway). (Official releases are in a bit of a weird holding pattern. distribute's versioning scheme leads to potential confusion: if I release e.g. 0.6.1, then it sounds like it's a lesser version than whatever distribute is up to now. OTOH, releasing a later version number than distribute implies that I'm supporting their feature enhancements, and I really don't want to add new features to 0.6... but don't have time right now to clean up all the stuff I started in the 0.7 line either, since I've been *hoping* that the work on packaging would make 0.7 unnecessary. And let's not even get started on the part where system-installed copies of distribute can prevent people from downloading or installing setuptools in the first place.)
Welp, I don't want to get in the middle of that whole mess. But maybe the distribute folks would be kind enough to do a major version bump in their next release; e.g. 1.67 instead of 0.67. That said, I don't think anyone would be confused by overlapping version numbers between the two projects. It's known that they have been diverging for a while.
- C _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
