On 31 August 2015 at 14:32, Nick Coghlan <ncoghlan@gmail.com> wrote:
This is why I think it's important to be clear that we *want* to improve the off-PyPI hosting experience, as that's something we consider reasonable for people to want to do, but it's going to take time and development effort.
+1 It's important also that we get input from people who need off-PyPI hosting, as they are the people with the knowledge of what's required.
The question is thus whether it makes sense to delay significant improvements for the common case (i.e. hosting on PyPI), while we work on handling the minority case, and I don't believe it does.
Agreed again. IMO, our initial responsibility is to get a solid, stable baseline functionality. The principle behind the PEP is that getting packages from anywhere other than PyPI must be an opt-in process by the user. That's a basic consequence of the idea that users should know who provides the services they use, combined with the fact that PyPI is the official Python repository. We've provided an option based on those principles for people who host off-PyPI, and there's no reason we couldn't improve that solution, but the principle should remain - users choose which package providers to use and trust.
It *may* be worth hacking in special case handling for the packages already hosted externally, but we can do that as exactly that (i.e. a special case providing a legacy bridging mechanism until a better solution is available), rather than as an indefinitely supported feature.
Hmm, I'm not aware of any concrete suggestions along those lines. According to the PEP, 3 months after it is implemented all projects on PyPI will be in pypi-only mode, and all of the other legacy modes will be unavailable, and unused. No external links will be visible, no link-scraping will occur, and the relevant code could be removed from installer tools such as pip. Are you suggesting that this shouldn't occur? Paul