<div><span style="color: rgb(160, 160, 168); ">On Wednesday, February 27, 2013 at 8:34 PM, Aaron Meurer wrote:</span></div>
<blockquote type="cite" style="border-left-style:solid;border-width:1px;margin-left:0px;padding-left:10px;">
<span><div><div><div>On Wed, Feb 27, 2013 at 6:24 PM, Donald Stufft <<a href="mailto:donald.stufft@gmail.com">donald.stufft@gmail.com</a>> wrote:</div><blockquote type="cite"><div><div>On Wednesday, February 27, 2013 at 8:13 PM, PJ Eby wrote:</div><div><br></div><div>On Wed, Feb 27, 2013 at 7:36 PM, Donald Stufft <<a href="mailto:donald.stufft@gmail.com">donald.stufft@gmail.com</a>></div><div>wrote:</div><div><br></div><div>This seems a bit complicated, people in general don't even know</div><div>the external link spidering exists, much less understand the intricacies</div><div>of what types of links get spidered when. A simple "After X date no new</div><div>urls will be added and after Y date all existing urls will be removed"</div><div>removes ambiguity from the process. Having "this kind of link will get</div><div>removed Y</div><div>and that matters in Z conditions" leads to a lot of confusion about</div><div>what does and doesn't work.</div><div><br></div><div><br></div><div>AFAICT, that's an argument in *favor* of phased removals, not against.</div><div>(Also, you have the order backwards from my proposal, which is to</div><div>*first* remove broken old junk in two phases. This is actually *less*</div><div>problematic than doing it for new releases first. And of course the</div><div>simplest thing of all would be to make no change at all.)</div><div><br></div><div>The phased removals are a problem when people won't understand</div><div>the differentiating factors between the different phases.</div><div><br></div><div><br></div><div>Anyway, let's try to be a little bit less like the politicians who,</div><div>upon being told that "Something must be done!", turn around and pick</div><div>any arbitrary value of "something", and do that, so as to be seen to</div><div>be "doing something".</div><div><br></div><div>But that is *exactly* what is happening now: people are proposing to</div><div>create worse problems down the line by insisting on doing something</div><div>"right now" (although never is often better, per the Zen of Python)</div><div>without considering the consequences that will happen six months or so</div><div>from now... when the users and toolmakers move the external links</div><div>someplace else, that will have even *less* visibility,</div><div>maintainability, and trust than they have now.</div><div><br></div><div>This is not something I've just cooked up, It's been thought about since</div><div>I stood up Crate a year ago, infact there is a /simple/ index on Crate</div><div>that flat out removes external links (as well as all the breakage that</div><div>occurs).</div><div><br></div><div>I'm well aware of the implications here. dependency_links cannot be</div><div>controlled</div><div>via PyPI (and infact require a download to even trigger them if they are in</div><div>setup.py) so that problem is outside of the realm of PyPI. Like I said I've</div><div>already opened issues with pip/buildout about this, and I have every</div><div>intention of seeing them through till completion.</div></div></blockquote><div><br></div><div>Can you give the links to the issues in their issue trackers, for</div><div>those of us who want to follow the progress of this more closely?</div></div></div></span></blockquote><div><a href="https://github.com/pypa/pip/issues/818">https://github.com/pypa/pip/issues/818</a></div><div><br></div><div><a href="https://github.com/buildout/buildout/issues/92">https://github.com/buildout/buildout/issues/92</a> </div><blockquote type="cite" style="border-left-style:solid;border-width:1px;margin-left:0px;padding-left:10px;"><span><div><div><div><br></div><div>Aaron Meurer</div></div></div></span></blockquote><div><br>
</div>