[Distutils] some questions about PEP470

[Nick Coghlan]

On 12 October 2014 09:49, Donald Stufft <donald at stufft.io> wrote:
>
> On Oct 11, 2014, at 7:48 PM, Nick Coghlan <ncoghlan at gmail.com> wrote:
>
>> On 12 October 2014 04:29, Donald Stufft <donald at stufft.io> wrote:
>>>> I plan to put the external repositories (and the commands needed to use them)
>>>> in the UI for PyPI. I suppose I should put that in the PEP as well, I was more
>>>> focused on defining the API differences and the changes.
>>>
>>> I forgot to mention, one other thing I thought about, we could move the current
>>> external links to external repositories automatically. I’m not sure if this is
>>> a good idea because on some projects that will end up with a giant list of things
>>> that a user would be suggested to install. Perhaps it’d work to scan them for
>>> installable files and only move the ones where an installable file was discovered,
>>> though that could be error prone (for example right now bytereef.org is down, so
>>> we’d not discover any files there).
>>
>> If I recall Holger's suggestion correctly, it was just to move the
>> current "Download URL" links over, rather than the scraped links.
>
> Hmm, I thought his suggestion was to just leave the existing links alone so that the
> existing pip/easy_installs would continue to function as they do now?

Sure, we could do that too. Regardless, I don't believe we should let
the conversion of the silent security failures into noisy exceptions
block the other usability enhancements - if decoupling the two
decisions will achieve that, then let's go down that path.

I think I suggested at one point that the PEP could potentially commit
to making the backwards compatible changes on the server side, and
then for the *in*compatible changes, only commit to *looking at the
numbers again* in a few months time after folks have had a chance to
experience the replacement model. Client applications would be
officially granted permission to ignore the PEP 438 external hosting
mechanism in favour of the new PEP 470 external index advertisements.

The sequence of events from a compatibility break/user experience
enhancement perspective would then be:

* new model added to PyPI (no compatibility break)
* old model dropped from pip (client side compatibility break, error
handling improvements)
* old model dropped from PyPI (conditional, based on changes in server metrics)

That changes the dynamic from "the updated user experience will be
better, trust us" to "if you prefer the old user experience, you can
keep using the old pip, if you prefer the new user experience,
upgrade".

The eventual decision on when to drop the legacy model from PyPI can
then by made based on a richer set of input data, that includes the
level of adoption of the new version of pip that treats all missing
link targets as potential errors.

Regards,
Nick.

-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia