On 4 October 2014 05:08, Donald Stufft <don...@stufft.io> wrote: > 2. This doesn’t actually prevent breakage, it just links the breakage to the > version of pip/easy_install someone is using at the cost that people with > older clients are implicitly fetching things, some of which may or may not > be safe. > > Overall I think the goal of not breaking things is a good one, however PyPI > isn’t a versioned thing where people can limit what version of things they > run. > It’s important just from a maintenance aspect to be able to deprecate and > remove things over time. This will break things for people depending on those > things of course, so it’s always a balancing act about deciding *when* exactly > to remove something. I think that this is a good time to remove this > particular > thing because the core functionality of it’s replacement has existed for a > long > time, the actual use of the feature is quite low, and leaving it in presents > an > issue with usability and security.
It occurred to me that it's potentially desirable to decouple the "stop advertising links for spidering from PyPI" step from the "stop supporting link spidering in the clients" step. My rationale is that the first is just about changing PyPI itself - more clearly splitting the "PyPI as index" and "PyPI as repository" roles. We can quantify that impact fairly clearly, and will have data to make informed decisions each step of the way. Removing the link spidering support from the *clients* is a potentially bigger deal, as it would impact anyone that was using link spidering *independently of PyPI*. We don't have any data on that, and it's a decision different clients may want to approach differently. So while PEP 470 would allow clients to *consider* dropping link spidering support (and any new clients would be free to never add it), it likely doesn't make sense for the PEP to commit any clients (including pip) to a particular time frame for dropping the feature. That would narrow the scope to just server side PyPI changes (with client updates to report the availability of external repositories being a quality of implementation issue rather than a hard requirement). Regards, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia _______________________________________________ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig
