> On Oct 4, 2014, at 3:46 AM, Nick Coghlan <[email protected]> wrote: > > On 4 October 2014 05:08, Donald Stufft <[email protected]> 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).
Yea, I don’t think I included what the installers do in this PEP other than the parts specific to this PEP, so: 1. Implement multiple repository support. 2. Implement some mechanism for removing/disabling the default repository 3. Implement the discovery mechanism. 4. Deprecate / Remove PEP 438 I purposely don't give exact details how it should be done, as I think that each installer should decide how best to integrate that within their own UX. --- Donald Stufft PGP: 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA _______________________________________________ Distutils-SIG maillist - [email protected] https://mail.python.org/mailman/listinfo/distutils-sig
