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 <[email protected]>: > > On May 14, 2014, at 5:33 PM, M.-A. Lemburg <[email protected]> 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" <[email protected]> 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 - [email protected] > https://mail.python.org/mailman/listinfo/distutils-sig > >
_______________________________________________ Distutils-SIG maillist - [email protected] https://mail.python.org/mailman/listinfo/distutils-sig
