[Catalog-sig] What is the point of pythonpackages.com?

[Donald Stufft]

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<faassen at startifact.com (mailto:faassen at startifact.com)> 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
> Catalog-SIG at python.org (mailto:Catalog-SIG at python.org)
> http://mail.python.org/mailman/listinfo/catalog-sig
>  
>  


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/catalog-sig/attachments/20120206/7cecf008/attachment.html>