On 12 October 2014 09:49, Donald Stufft <[email protected]> wrote: > > On Oct 11, 2014, at 7:48 PM, Nick Coghlan <[email protected]> wrote: > >> On 12 October 2014 04:29, Donald Stufft <[email protected]> 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 | [email protected] | Brisbane, Australia _______________________________________________ Distutils-SIG maillist - [email protected] https://mail.python.org/mailman/listinfo/distutils-sig
