On Wednesday, February 27, 2013 at 8:34 PM, Aaron Meurer wrote: > On Wed, Feb 27, 2013 at 6:24 PM, Donald Stufft <donald.stu...@gmail.com > (mailto:donald.stu...@gmail.com)> wrote: > > On Wednesday, February 27, 2013 at 8:13 PM, PJ Eby wrote: > > > > On Wed, Feb 27, 2013 at 7:36 PM, Donald Stufft <donald.stu...@gmail.com > > (mailto:donald.stu...@gmail.com)> > > 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 Catalog-SIG@python.org http://mail.python.org/mailman/listinfo/catalog-sig
