Re: Deprecate External Links

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

https://github.com/pypa/pip/issues/818

https://github.com/buildout/buildout/issues/92 
> 
> Aaron Meurer

_______________________________________________
Catalog-SIG mailing list
[email protected]
http://mail.python.org/mailman/listinfo/catalog-sig