[Python-Dev] pip: cdecimal an externally hosted file and may be unreliable [sic]

[Donald Stufft]

On May 8, 2014, at 5:02 PM, Paul Moore <p.f.moore at gmail.com> wrote:

> On 8 May 2014 16:46, Donald Stufft <donald at stufft.io> wrote:
>> Anything can be changes or reconsidered of course. I feel pretty strongly that
>> an installer should not install things from places other than the index without
>> a specific opt in. That discussion would be best done on distutils-sig as it
>> would require reversing the decision in PEP438.
> 
> I think it's worth reconsidering. Since this behaviour was
> implemented, there have been many instances of confusion and
> unhappiness with the situation, both from package developers and pip
> users. I don't think that's good for pip. I would like to see PEP 438
> reviewed with the intention of working out how to fix the user
> experience (ideally while retaining the reliability enhancements, but
> accepting that compromises may be needed).

I think most of the confusion has been over the fact that —allow-external
takes a package name, not that it exists at all.

> 
> Some points:
> 
> 1. Often a user won't know that a package is externally hosted until
> an install fails. Having to add a flag and retry is a lousy
> experience. Why not at a minimum have an "externally hosted - are you
> sure?" prompt?

A prompt is OK with me.

> 2. The way the flags are implemented (notably the need to repeat the
> package name) is clearly confusing and irritating for users, even if
> the reasons are logical. We should look at fixing that.

Yea, there’s a ticket for this.

> 3. The user complaints against pip are significant and ongoing. I
> don't think they should be ignored. If PEP 438 cannot be reconsidered
> in the light of user feedback, then I think the pip developers may
> need to have a discussion about whether we conform to the PEP (clearly
> Donald thinks we should, I'm not sure I do, and I don't know about the
> others). But I don't think it's healthy for pip to be looking at
> deliberately ignoring an accepted PEP, so I'd prefer it if the debate
> was around addressing the issues in the PEP itself.

I don’t think the problem with with the PEP.

> 4. Maybe distutils-sig *isn't* the right place to discuss revising PEP
> 438. The issues getting raised are end-user problems, and the users
> most affected are unlikely to be on that list.
> 
> Socially, this change does not seem to be having the effect of
> persuading more package developers to host on PyPI. The stick doesn't
> appear to have worked, maybe we should be trying to find a carrot?

Do you have any data to point to that says it hasn’t worked? Just to see
what impact it has had, I’m running my scripts again that I ran a year
ago to see what has changed, already I can see they are processing
MUCH faster than last year.

> Or
> maybe we have to accept that some developers have sound reasons for
> not hosting on PyPI and work with them to find an acceptable
> compromise? Has anyone checked what Stefan's reasons are for not
> hosting cdecimal on PyPI? Do they represent a use case that the PEP
> hasn't considered?

If I recall correctly his reasoning is that he finds the legal requirements
associated with uploading to PyPI to be unsatisfactory.

> 
>> I really don't feel strongly one way or the other about the *warning* that
>> happens when you allow an external file. It exists primarily because at the
>> time it was implemented external files were default to allowed.
> 
> I think it's reasonable to remove the warning. If the user chooses to
> allow an external file, it makes sense to assume they understand the
> implications and not nag them about their decision. Particularly given
> the level of controversy the warning is generating.

The warning is gone as of a few hours ago.

> 
> On a personal note, I'm uncomfortable with the way this change is
> perceived as a case of *pip* enforcing a behaviour that the pip
> developers feel should be required. I actually don't like this change
> particularly. So having pip implement the behaviour required by that
> PEP is to me simply a case of compliance with the agreed standard. But
> now, as a pip developer, being held responsible for the resulting user
> pain, and being expected to defend it, does not make me happy.
> 
> Paul

I think the pain is being overrepresented and the positives are being ignored.
The problem is the benefits of this PEP are much like the benefits of TLS
too. For the vast majority of people they don’t notice anything different except
installing things is faster and more reliable. They don’t attribute that to the
PEP or this decision, they just internalize it as the new norm. However the
people who this does affect will seek out why it broke and raise an issue
citing that thing specifically. This creates a perception of lots of pain for no
gain when the reality is not that.

-----------------
Donald Stufft
PGP: 0x6E3CBCE93372DCFA // 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://mail.python.org/pipermail/python-dev/attachments/20140508/f77af49c/attachment-0001.sig>