[Distutils] PEP 470, round 4 - Using Multi Repository Support for External to PyPI Package File Hosting

[Donald Stufft]

> On Oct 4, 2014, at 3:46 AM, Nick Coghlan <ncoghlan at gmail.com> wrote:
> 
> On 4 October 2014 05:08, Donald Stufft <donald at 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).

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