On 9 May 2014 22:33, Donald Stufft <don...@stufft.io> wrote: > On the flip side option (A) allows us to make this much simpler overall. We > can simply do: > > If it's hosted on PyPI: > Trust it. > else if it's not hosted on PyPI: > Require a --allow-external-and-unverifiable [*] > > This is *much*, *much*, *much* easier to explain, and I think it may be a good > idea ala the Zen. [...] > Actually my opinion is that allowing external+safe files by default is not > going to have any meaningful impact to *any* (or at the very least, 99.9%) of > pip's users.
Thank you for the detailed explanation (most of which I trimmed). I am now 100% convinced of what you're saying. As to the option name, I think that --allow-external makes sense. It describes what we're doing, and we can explain why it is opt-in on the basis that (something like): """ There are a number of issues with off-PyPI downloads. Apart from the fact that the infrastructure team cannot provide support for such downloads, nearly all such downloads are not verifiable, and hence represent a risk to the user. There is a mechanism for verifying off-PyPI downloads, but only a tiny minority of packages (around 0.05%) use it, and as the reliability issues still exist, opt-in remains the correct default.. """ If there's a sudden growth in safe off-PyPI downloads, we could add an --allow-safe-external option that allowed *all* safe off-PyPI links (it's not worth having a per-package option, IMO). But I doubt it'll ever be needed. Paul. _______________________________________________ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig
