[Distutils] PEP 438, pip and --allow-external (was: "pip: cdecimal an externally hosted file and may be unreliable" from python-dev)

[Nick Coghlan]

On 10 May 2014 22:24, "Paul Moore" <p.f.moore at gmail.com> wrote:
>
> On 10 May 2014 12:57, Nick Coghlan <ncoghlan at gmail.com> wrote:
> > Actually, I expect folks like Stefan & MvL would likely want to be able
to
> > preserve the  current "--allow-external" behaviour. The change Donald is
> > suggesting could then just be a matter of renaming the current
> > "--allow-external" to "--allow-safe-external", and making
"--allow-external"
> > and " --allow-unverifiable" synonyms.
> >
> > The error messages would still recommend "--allow-external", since that
is
> > likely what would be needed to solve any installation problems related
to
> > externally hosted files.
>
> The thing is, the current --allow-external helps basically no-one. If
> the people who wanted the behaviour preserved switched their packages
> to include hashes, so that they didn't *also* need
> --allow-unverifiable, then keeping both (in some form) would make more
> sense. But at the moment, the *only* people who can justifiably say
> they want --allow-external to be retained are the authors of the
> 26[1][2] verifiable but external packages on PyPI, and that's not a
> big enough group to justify the confusion caused by having two similar
> but subtly different options.

You are talking about a backwards compatibility break, that potentially
creates a security vulnerability without providing a programmatic solution.
This is *not* OK, even if the number of affected packages on PyPI is small.
And yes, it does matter if the group includes Stefan & MAL, because they
have both donated an incredible amount of work to the Python community over
the years, and deserve serious respect and consideration from other
community members.

The current confusion arises from the names of the options: the obvious
name "allow external" is claimed by the option people *don't* want, leaving
the obscure "allow unverifiable" name for the option people actually need.

This confusion can likely be resolved by giving the obvious "allow
external" name to the behaviour most users will want, and a more obscure
name like "allow verifiable external" to the specialised behaviour folks
like Stefan & MAL rely on.

Now, if the pip devs want to say to Stefan & MAL, "FU, we don't give a damn
about your problems, and are just going to take away this feature entirely
instead of trying to find a less drastic compromise", that's your call.
However, that approach seems like poor user engagement to me (since
renaming the existing option is just as easy as removing the associated
code entirely), and a poor use of social capital that could be better spent
on more significant problems like getting ensurepip into Python 2.7.8.

Regards,
Nick.

>
> Paul
>
> [1] See Donald's email. "And looking even closer at those, only 0.07%
> (26) of them will have the outcome of ``pip install whatever`` change
> (in other words, the latest version requires external+safe)."
> [2] Apologies if Stefan and MAL are among those authors - it's not
> clear to me if that's the case from the information I have. But even
> if they are, the numbers argument is still pretty compelling.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/distutils-sig/attachments/20140511/74c0c52a/attachment.html>