On 8 July 2018 at 15:41, Nathaniel Smith
On Sun, Jul 8, 2018, 04:25 Paul Moore
wrote: In principle, I'm 100% on board with this. However, as is typical with packaging changes, we have a huge backward compatibility situation to address - the many packages on PyPI that are infrequently updated or maintained and yet still in common use. We also have a large body of users who build pip into their internal workflows, who often rely heavily on what to "normal pip usage" are obscure edge cases. I'd like to find some way of assessing the impact before we simply switch to full build isolation (we've already had a fair number of bug reports on pip that are triggered by build isolation, such as the ones that started this discussion).
I think it would be helpful for this discussion if we could look at these bug reports – do does anyone have links?
Good point. I will hunt them out and post here.
Every new rollout will cause some issues. The crucial thing IME is to see whether they're bugs in the implementation we can fix, whether there's a simple way to improve error messages for other cases, ... etc. If they're intractable issues that's very different than if they're teething pains :-)
Agreed. My impression (and it is only an impression) is that the main issue is with people being taken by surprise with new behaviour, which is a combination of things: 1. Poor communication (as noted earlier, we struggle to even reach many of our users) 2. A general principle of "you should use the latest pip" (i.e., our check and warning for if you're using the current version) 3. People using pip in ways we didn't consider I think it's important that we don't let the standardisation and improvement process get stalled by a fear of affecting people's workflows, but at the same time I think we should consider transition paths. Paul