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

[M.-A. Lemburg]

On 09.05.2014 17:39, Donald Stufft wrote:
> 
> On May 9, 2014, at 9:58 AM, M.-A. Lemburg <mal at egenix.com> wrote:
> 
>> On 09.05.2014 13:44, Donald Stufft wrote:
>>>
>>> On May 9, 2014, at 4:12 AM, M.-A. Lemburg <mal at egenix.com> wrote:
>>>> Donald: I don't think anyone is arguing that hosting packages on
>>>> PyPI is a bad thing and PyPI as a service has gotten a lot better
>>>> than it was a few years ago.
>>>
>>> Didn’t mean to imply that I thought it was otherwise.
>>>
>>>>
>>>> However, I find it troubling that we as Python developers are *forcing*
>>>> the whole Python world to put their code into PyPI.
>>>
>>> Forcing is a strong word. As of right now we’re "forcing" you to put it onto
>>> PyPI if you want to install it without *any* flags to pip. 
>>
>> Which is what most people expect to be able to do.
> 
> Sure, but sometimes it’s better to make an informed choice about things being
> installed instead of having it be installed by default and sometimes it’s better
> to disallow doing something at all.
> 
> Further most people don’t expect an install to touch any server host other
> than PyPI. 

For some idea of "most people" that's probably true.

I'd argue that most people probably don't really care all that
much where their packages are coming from as long as they
are getting the packages registered with PyPI, the Python
package index, and can be sure that no one has tampered with
them.

But both arguments don't really count much, since it's all
speculation.

> As far as I’m aware none of the other package repositories
> feature this, and even with the fact we support it barely anyone even cares to
> utilize it.

Most Linux repos comes with a list of standard repos to include.

In Python land, Plone uses zc.buildout with a similar
default list of repos.

>>> You're more then
>>> capable of hosting it externally if you wish, and pip will even tell the people
>>> who try to install it what they need to enable in order to install it. It even
>>> allows people to say "I don't care about any of this crap, just make all the
>>> external stuff work".
>>>
>>> Even if pip removed the external link handling all together and required you
>>> to do something like:
>>>
>>>    $ pip install --extra-index-url https://example.com/our-packages/ foo
>>>    $ pip install --find-links https://example.com/our-packages/ foo
>>>
>>> We still wouldn't be forcing anyone to upload things to PyPI. We are, however,
>>> discouraging people from not hosting on PyPI and providing incentives to doing
>>> that.
>>
>> This is all true, but in reality, you are making externally hosted
>> packages second class citizens in Python land by requiring
>> extra options even for package listings that are perfectly safe
>> to download from other servers.
>>
>> As mentioned before: I can understand that you want to make downloads
>> safe for users, but if a package is hosted on some other reliable
>> servers and pip can check that it's a valid package, there's little
>> to argue for not allowing such downloads.
> 
> Except the fact that the only people I’ve ever seen *happy* that people can
> host packages externally are a handful (<5) of people (tbh primarily you and
> Stefan) and the feedback I get from every other person around the web
> in unequivocally yes please get rid of externally hosted files, they’ve done
> nothing but cause me pain.
> 
> It’s not reasonable to allow a minority of users to negatively impact the majority.

I think you're getting this wrong:

There *are* package authors who would like to host PyPI indexed
packages external to PyPI and they all have good reasons to
do so. It may well be a minority, but that's fine.

Changing the default to allow secure external downloads is *not*
impacting any majority.

At worst, it's impacting the users of those packages, but that's
really within the realm and responsibility of the package authors,
not PyPI or the infrastructure team, so I don't understand why you
are strongly objecting this.

>>>> There are plenty good reasons not to do this, and sometimes it's
>>>> even impossible if you want to stay legal (see the PEP for details).
>>>
>>> I re-read the reasons, I'm not sure I really agree with most (or all?) of them
>>> however if people really want to do it, then there is nothing stopping them.
>>> It's their choice and people on the *other* side of that who are installing
>>> these packages also get to make a choice if they want to allow it or not.
>>
>> You don't have to agree with those reasons. Fact is, they exist,
>> prevent package authors from uploading to PyPI and we as
>> Python developers should respect those reasons.
> 
> No I disagree that they are reasons at all. Half of the ones you enumerated are
> nonsensical or irrelevant, the other half can be fixed by adding features to or
> fixing PyPI. One or two read like reasons why someone might actually decide
> not to upload something to PyPI but which that reason isn’t really all that
> reasonable and finally a grand total of one or two of them look like an actual legit
> reasons and it only applies to Crypto software.

I guess continuing this discussion doesn't really make any sense.
I'm trying to respect your reasoning, but you are apparently
not respecting mine. Without such respect there's no basis for
a discussion.

Thanks,
-- 
Marc-Andre Lemburg
eGenix.com

Professional Python Services directly from the Source  (#1, May 09 2014)
>>> Python Projects, Consulting and Support ...   http://www.egenix.com/
>>> mxODBC.Zope/Plone.Database.Adapter ...       http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ...        http://python.egenix.com/
________________________________________________________________________

::::: Try our mxODBC.Connect Python Database Interface for free ! ::::::

   eGenix.com Software, Skills and Services GmbH  Pastor-Loeh-Str.48
    D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg
           Registered at Amtsgericht Duesseldorf: HRB 46611
               http://www.egenix.com/company/contact/