[Distutils] Need for respect

[Mark Young]

I know I'm just an anecdote, but as just a regular user of pypi, pip, and
friends (I've never even posted something to pypi), when I say "pip install
spam", I don't really care where it comes from and I have no expectation
that pip has to get it from pypi.


2014-05-14 18:24 GMT-04:00 Donald Stufft <donald at stufft.io>:

>
> On May 14, 2014, at 5:33 PM, M.-A. Lemburg <mal at egenix.com> wrote:
>
> > On 14.05.2014 22:56, Donald Stufft wrote:
> >> On my phone so I can't respond to everything here but I just want to
> say I don't think a discussion where we can't challenge each other's
> conclusions isn't going to go anywhere. Hopefully we are adults and can
> handle disagreement.
> >
> > There's nothing wrong with disagreeing on conclusions and
> > agreeing on this disagreement, but trying to shut someone down is
> > not the right way forward.
> >
> > What I'm trying to get back into the discussion is the view on
> > PyPI as a community resource, which does not only need to address
> > the needs of users of installers, but also those of developers who
> > register their packages with it and make the whole thing come to
> > life.
> >
> > PyPI is used by people through the browser, it's used by people
> > with installer tools such as pip, easy_install, zc.buildout, conda, etc.
> > and it's used by developers using distutils, setuptools and
> > other build tools that can talk to the PyPI API.
> >
> > All of these people have needs and requirements, so we need to
> > find ways to make most of them happy. In discussions on this list,
> > I often get the feeling that the package authors are underrepresented,
> > and that's why I try to add some of package author views to
> > the discussion and also views as user of other tools than pip.
> >
> >>> On May 14, 2014, at 4:26 PM, "M.-A. Lemburg" <mal at egenix.com> wrote:
> >>>
> >>> Noah, please reread the subject line and the message that started
> >>> this thread. If we want to have a useful discussion, calling someone's
> >>> conclusion incorrect is not helpful.
> >
>
> Of course PyPI is a community resource and package authors are important. I
> know that intimately since I publish several things through PyPI that I
> wrote
> and I'm involved with several other projects. I suspect most people on this
> list have published at least one package. If anything we are top heavy in
> the viewpoints of authors with practically no representation from people
> who
> just want to install some stuff.
>
> I *know* that users have the expectation that installing something from
> PyPI
> means they are downloading it from PyPI. I know this because they tell me
> this,
> constantly. I've dealt with users every single day who are struggling to
> deal
> with the concepts introduced in PEP 438. Whenever I explain to them that
> pip
> will scan PyPI for links to places that are not PyPI they think that is
> just
> crazy. It completely violates their expectations. The *only* people I have
> ever
> seen *not* surprised by that, are people who happen to already know how
> pip/setuptools/etc works. Most of those people that also think it's crazy
> that
> they do that but they aren't surprised by it.
>
> Framing the hosting of files on PyPI as an "extra" feature makes it appear
> to
> be something added that isn't part of it's core competency. Nothing could
> be
> further from the truth. For most people, authors and users, the fact that
> PyPI
> host packages *is* what PyPI is. A mere 7% of projects that are registered
> with PyPI have any reliance what so ever on externally hosted files. The
> vast
> bulk of those are projects where the author forgot to upload a file or two
> and external hosting isn't their primary hosting method.
>
> That being said, nobody is trying to mandate that everyone must upload to
> PyPI.
> I've put forward a PEP that proposes a way to resolve the problems with
> reliability and implicitness of the current method of not hosting PyPI with
> centralizing around the multiple index/URL support. There are changes to
> PyPI
> in that proposal to increase the discover-ability of the additional indexes
> however I ultimately think that it is the right path forward which brings
> PyPI
> inline with what the vast bulk of people (authors and users) expect but
> still
> preserves the ability for people who don't want to, to not host on PyPI as
> well
> as reduce the number of ways that users have to be aware of for things not
> being hosted on PyPI. It follows a pattern that many users are used to
> through
> their dealings with OS packages and other languages, it allows them to
> explicitly opt in to where they install packages from, and it allows a
> whole
> bunch of UX issues in the current tools to just be eliminated.
>
> Please go view that proposal (PEP 470, I posted it to distutils-sig earlier
> today) and comment on it.
>
> -----------------
> Donald Stufft
> PGP: 0x6E3CBCE93372DCFA // 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372
> DCFA
>
>
> _______________________________________________
> Distutils-SIG maillist  -  Distutils-SIG at python.org
> https://mail.python.org/mailman/listinfo/distutils-sig
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/distutils-sig/attachments/20140514/9e4c535a/attachment-0001.html>