On May 9, 2014, at 8:46 AM, Paul Moore <[email protected]> wrote: > On 9 May 2014 13:17, Donald Stufft <[email protected]> wrote: >> I replied on python-dev already, but I’m still heavily -1. > > Yeah, I have no idea if the discussion will migrate here or not, but I tried > :-) > >> This isn’t actually going to help hardly anyone since almost no packages are >> hosted safely externally. I think the only practical affect is that the >> latest version >> of argparse will be installable. > > The same argument could be made about implementing the external > hosting restriction in the first place. From the figures you posted on > python-dev:
I don’t really agree. There is a difference in allowing a problematic “footgun” feature by default vs disabling it and requiring it to be opted in to. A feature that has a high footgun factor (tm) needs to have a pretty large subset of users > >> * We've gone from 86% of projects being installable from PyPI to 92%. >> * We've gone from 5% of projects being only unsafely installable to 3% >> * We've gone from 14% of projects having any files unsafe to install to 8% >> * We've gone from 0.004% of projects being safely hosted externally to 0.2% > > There's a lot about unsafe installs here, which is a distraction, but > it seems to me that safe external hosting has gone from 0.004% to > 0.2%. Maybe a substantial chunk of this is projects making external > downloads safe, so let's assume that no new projects have been added > that are externally hosted (safely). So this whole feature only > affects 0.2% of PyPI at best. > > I wish this feature had never been added, because there is *no way* > that the benefits (between 0.004% and 0.2% of PyPI) justify the amount > of time discussing it, dealing with bug reports about it, etc. Please > again note that this is SOLELY the default rejection of SAFE external > hosting. Figures and arguments about unsafe hosting aren't relevant > here. Almost all of the bug reports that I’ve seen come into pip are about projects that are unsafely hosted. The *only* bug report i’ve ever seen that is related to a safely hosted external project are people who depended on argparse==1.2.1 as that suddenly went missing by default. I think that you’re conflating any bug report about these two flags with bug reports about externally hosted things at all. > >> I think if we actually care about end user confusion the actual thing to do >> is remove >> the concept of safe externally hosted all together and just make it Hosted on >> PyPI Y/N? If it is install it if it isn’t require a per package flag. > > I am strongly -1 on any such suggestion. The concept of *unsafe* > hosting is crucially important. The fact that it's external is > peripheral, simply because we ensure that PyPI is safe. We already > have --allow-unverified and a default of not allowing unverified > downloads. I'm arguing that we don't need a second set of flags, and > that the confusion is that users see the 2 sets of flags and assume > that both conditions are somehow equally bad. My argument is that a second set of flags is moderately confusing but that the fact that externally hosted files have a high footgun factor means that it would be more reasonable to err on the side of not installing the tiny handful of projects that rely on it. > > BTW, you didn't respond to my point: > > Previously, > `pip install foo` - works in all but a few cases where foo's host is down > > Now > `pip install foo` - fails immediately, 100% of the time > `pip install --allow-external foo foo` - works in all but a few > cases where foo's host is down > > How is the second better for the pip user than the first? What did the > user learn that they can actually use to improve things for themselves > in any way, assuming that they already knew foo is externally hosted? Think of it kind of like the implicit coercion to unicode in Python2 vs the explicit encoding/decoding in Python 3.x. Proposed situation: ``pip install foo`` where foo is hosted externally will work (probably) when the developer first does it, they add it to their requirements.txt and go on their merry way. Similarly b"unknown" + u"known" will likely work for most developers when they first write it (given that most developers deal with ascii). Then sometime down the road the server for foo goes missing. It could be because there is a temporary outage, it could be because they were hosting on bitbucket.org and they started to get rate limited, it could be the author went MIA and his server got shut down. Whatever the reason that server is gone. The developer then tries to do his ``pip install -r requirements.txt`` and suddenly it fails. This developer knows that pip installs from PyPI so he goes to pypi.python.org and sees it works fine in his browser, he goes to status.python.org and sees there are no downtimes. Now he's left trying to discover the reason why all of a sudden one particular package is no longer installable but the website he thought he was interacting with is up and responding to his browser just fine! This user is confused and angry. Current situation #1: ``pip install foo`` where foo is hosted externally fails. The developer is told that this file is hosted externally and might be unavailable in the future. They decide they don't care and they just want a thing to work so they add ``--allow-external foo`` to their requirements.txt and go on their merry way. The sometime down the road the server for foo goes missing. This time however the developer knows that this file isn't hosted on PyPI so he doesn't get confused and trying to figure out why PyPI is down but looks up to them. Maybe they forget that they've allowed externally hosted files (or which ones) but there is an easy reminder right there in their requirements.txt in the form of the --allow-external foo. Developer is angry, but knows to contact the authors of foo to tell them their host is down. Current situation #2: ``pip install foo`` where foo is hosted externally fails. The developer is told that this file is hosted externally and might be unavailable in the future. They decide that they prefer not to rely on something that is hosted externally and they install a competitor to foo called bar. They never have any problems with bar being uninstallable and are happy. > > I'll give up the fight at this point. I don't know this part of the > pip code well enough to offer a patch implementing my suggestion, and > in any case I think that duelling patches is a very unhealthy thing > for a project. So as you did the work, I'll accept your view. But > could I ask that in future debates like this, if anyone suggests that > the pip developers are mandating the current behaviour, that mistake > is immediately corrected to point out that it's the PEP 438 authors > who are in fact doing this (and that pip is merely following the > requirements in that PEP)? I will certainly do this myself. > > Paul ----------------- Donald Stufft PGP: 0x6E3CBCE93372DCFA // 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA
signature.asc
Description: Message signed with OpenPGP using GPGMail
_______________________________________________ Distutils-SIG maillist - [email protected] https://mail.python.org/mailman/listinfo/distutils-sig
