A big +1 to hosting everything on PyPI
On Monday, February 6, 2012 at 12:13 PM, Alex Clark wrote: > Hi > > On 2/6/12 11:15 AM, Daniel Greenfeld wrote: > > On Mon, Feb 6, 2012 at 7:32 AM, Martijn Faassen<[email protected] > > (mailto:[email protected])> wrote: > > > > > This because setuptools (and thus, easy_install, pip, buildout) for better > > > or for worse uses a "trawl the web" approach to find download links, and > > > multiple sites to download from create multiple potential points of > > > failure > > > besides PyPI itself. > > > > > > This makes setuptools work for a range of cases and that's nice, but it's > > > also a drawback, because on a fairly regular basis I at least have had the > > > issue that a package wasn't hosted on PyPI and that the site hosting the > > > package was suddenly down or had changed, breaking the setuptools-based > > > automatic download. If the package were hosted on PyPI I wouldn't have had > > > this issue, as PyPI itself is actually tolerably reliable (especially with > > > mirroring in place; but these external packages are also not mirrored). > > > > > > Of course the response I'll undoubtedly get is that I should host these > > > packages myself or include them in my version control system and all that. > > > And yes, I can do this, and sometimes I do. But doing that is in this > > > subjective user's opinion actually an inconvenience. Any 'pip' user that > > > installs a package from PyPI that has dependencies listed in setup.py can > > > run into this problem. > > > > > > So the original poster could at least consider uploading their package on > > > PyPI to lessen his complaint. Besides the web UI, they'll find handy tools > > > available to help automate things, such as 'setup.py sdist upload' and for > > > more power, zest.releaser. But of course they can choose not to do so at > > > all > > > too - that's the way things work [1]. > > > > > > Regards, > > > > > > Martijn > > > > > > [1] I suspect an alternate timeline in which setuptools had never done > > > this > > > web trawling and would only download from PyPI would have lead to a more > > > pleasant situation for users, though I'm not sure: setuptools being able > > > to > > > download dependencies might've retarded adoption of setuptools instead. > > > > > > > > > I agree 100% with Martijn. Maybe there was a time when hosting your > > package off of PyPI was a good idea. I think if that time existed, it > > has now passed. Normally I prefer giving package authors more control, > > but this is one of those places where the users of the service ought > > to be able to expect packages to all be found in one location. > > > > > > +1. And if you want to host your packages off-site I think that is > perfectly reasonable. But it would make everyone's life easier if we > knew that: for every release of a Python package on earth, there is a > corresponding package on PyPI. > > E.g. In Plone-land we currently encourage dual-releasing to both PyPI > and plone.org/products (http://plone.org/products). This has several benefits: > > 0. Easy content creation. Having nice product pages for our add-ons is a > marketing win. > > 1. Everyone that runs buildout to install Plone can rely on packages > being found on PyPI. > > 2. If PyPI goes down, those folks can use an official PyPI mirror to > install the same set of packages[1] > > 3. If PyPI goes down, those folks can use plone.org/products[2] > (http://plone.org/products[2]) to > install any packages released to plone.org/products > (http://plone.org/products). > > There is also some disadvantage: > > 1. Folks rarely take advantage of #3. So I think in the future we may > consider replacing plone.org/products (http://plone.org/products) with a full > PyPI mirror and simply > rely on mirroring instead of dual-releasing. > > 2. Folks sometimes don't dual-release. Implementing the change suggested > in #1 of this list would fix that. > > > Alex > > > [1] In theory. I understand there has been some concern about the > stability/integrity of some mirrors lately. > > > [2] http://dist.plone.org/packages/ > > > > > -- > Alex Clark ยท http://pythonpackages.com > > _______________________________________________ > Catalog-SIG mailing list > [email protected] (mailto:[email protected]) > http://mail.python.org/mailman/listinfo/catalog-sig > >
_______________________________________________ Catalog-SIG mailing list [email protected] http://mail.python.org/mailman/listinfo/catalog-sig
