<div class="gmail_quote">On Thu, Jun 21, 2012 at 11:50 AM, Chris McDonough <span dir="ltr"><<a href="mailto:chrism@plope.com" target="_blank">chrism@plope.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="im">On 06/21/2012 11:37 AM, PJ Eby wrote:<br>
</div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">
<br>
On Jun 21, 2012 11:02 AM, "Zooko Wilcox-O&apos;Hearn" <<a href="mailto:zooko@zooko.com" target="_blank">zooko@zooko.com</a><br></div><div><div class="h5">
<mailto:<a href="mailto:zooko@zooko.com" target="_blank">zooko@zooko.com</a>>> wrote:<br>
><br>
> Philip J. Eby provisionally approved of one of the patches, except for<br>
> some specific requirement that I didn't really understand how to fix<br>
> and that now I don't exactly remember:<br>
><br>
> <a href="http://mail.python.org/pipermail/distutils-sig/2009-January/010880.html" target="_blank">http://mail.python.org/<u></u>pipermail/distutils-sig/2009-<u></u>January/010880.html</a><br>
><br>
<br>
I don't remember either; I just reviewed the patch and discussion, and<br>
I'm not finding what the holdup was, exactly. Looking at it now, it<br>
looks to me like a good idea... oh wait, *now* I remember the problem,<br>
or at least, what needs reviewing.<br>
<br>
Basically, the challenge is that it doesn't allow an .egg in a<br>
PYTHONPATH directory to take precedence over that *specific* PYTHONPATH<br>
directory.<br>
<br>
With the perspective of hindsight, this was purely a transitional<br>
concern, since it only *really* mattered for site-packages; anyplace<br>
else you could just delete the legacy package if it was a problem. (And<br>
your patch works fine for that case.)<br>
<br>
However, for setuptools as it was when you proposed this, it was a<br>
potential backwards-compatibility problem. My best guess is that I was<br>
considering the approach for 0.7... which never got any serious<br>
development time.<br>
<br>
(It may be too late to fix the issue, in more than one sense. Even if<br>
the problem ceased to be a problem today, nobody's going to re-evaluate<br>
their position on setuptools, especially if their position wasn't even<br>
based on a personal experience with the issue.)<br>
</div></div></blockquote>
<br>
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?<span class="HOEnZb"><font color="#888888"><br>
</font></span></blockquote><div><br>Yes. At the very least, there will be updated development snapshots (which are what buildout uses anyway).<br><br>(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.)<br>
<br>Anyway, changing this in a snapshot release shouldn't be a big concern; the main user of snapshots is buildout, and buildout doesn't use .pth files anyway, it just writes scripts that do sys.path manipulation. (A better approach, for everything except having stuff importable from the standard interpreter.)<br>
<br>Of course, the flip side is that it means there won't be many people testing the fix.<br></div></div><br>