<br><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><div><div class="im"><blockquote type="cite"><fieldset style="padding-top:10px;border:3px solid rgb(204,204,204);padding-left:20px"><div style="padding-left:3px">
<br>- - Distribute / setuptools merge, e.g. cratering folks who use a<br><span> </span> distro-managed 'python-distribute' package.<br></div></fieldset></blockquote><div><br></div></div><div>This is the biggest issue. I wasn't involved and it could have been handled better sure.</div>
</div></div></blockquote><div><br></div><div>what issue are we talking about exactly?</div><div><br></div><div>I'm aware of the "Import setuptools" problem during upgrades from distribute to setuptools:  <a href="https://github.com/pypa/pip/issues/1064">https://github.com/pypa/pip/issues/1064</a></div>
<div>pip-1.4 does prevent that now (released last week)</div><div><br></div><div>but you specifically mentioned the linux distro name, "python-distribute"? </div><div>I'm guessing maybe you're concerned with the scenario of how upgrading some project (that depends on setuptools/distribute) forces an unintended upgrade of distribute on a system where distribute is system-managed.</div>
<div>Is there a link to a tracker issue for that somewhere? </div><div><br></div><div>3 solutions to ponder:</div><div>1) unreleasing the distribute-0.7.3 wrapper, and making any upgrades from distribute to setuptools manual. </div>
<div>2) changing pip's -U logic to not recursively upgrade satisfied dependencies, but that's a *big* change (it's a long story, but there are tentative plans in 1.5 for changing it)</div><div>3) in a patch release, include a special case for distribute to *not* upgrade if satisfied (when distribute is a dependency in the requirement set).</div>
<div><br></div><div>Marcus</div></div>