[Catalog-sig] What is the point of pythonpackages.com?
donald.stufft at gmail.com
Mon Feb 6 21:25:38 CET 2012
It's your prerogative to host it where you will, but just from my personal point of view:
On Monday, February 6, 2012 at 3:08 PM, Stefan Krah wrote:
> Martijn Faassen <faassen at startifact.com (mailto:faassen at startifact.com)> wrote:
> > original poster's choice to host somewhere else, but it can indeed be
> > inconvenient to quite a few users of PyPI if a package is not hosted on
> > PyPI.
> I don't see any inconvenience since bytereef.org (http://bytereef.org) has a comparable
> uptime to python.org (http://python.org).
Even if your server has a _better_ uptime than PyPI, the combined downtime will be worse. (If PyPI is down the
user cannot install your package, or any package, if your server is down, but PyPI is up they cannot install your
package but can other packages.)
> I've listed my reasons for not hosting on PyPI earlier here:
> Stefan Krah
To address what was said here:
1) This is a valid complaint and should be brought up as a reason to amend the ToS (not particularly sure what the ToS is for PyPI tbh)
2) This complaint isn't particularly valid in the sense of should I upload my files to PyPI. You are already uploading the metadata that
they are scraping, otherwise you would be unable to list on PyPI. Wether or not you have a file hosted there won't make one bit of
difference to Google.
3) This is valid as well, I would argue that you should push for better package download stats for the authors of packages.
4) I think this is an invalid point as well, it's quite easy to add a Home Page metadata (as you already have done), and to
make your long_description state that the primary page for your package is at http://www.bytereef.org/mpdecimal/index.html
and to go there for that information.
5) I addressed this above but i'll reiterate this point, unless your server has (actual, not theoretical) 100% uptime as well as all
the networking routes between it and the end user, people installing your package have a greater chance of being unable to
install your package than if you just hosted on PyPi. You cannot remove their dependency on PyPI being up, but adding another
possible place for failure means that the combined uptime of your package being installable is lower.
Theoertical 99% uptime of PyPI and 99% uptime of your server would mean a combined 98% uptime. And that's without getting
into the additional points of failure between the person wanting to use your package and your server.
> Catalog-SIG mailing list
> Catalog-SIG at python.org (mailto:Catalog-SIG at python.org)
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Catalog-SIG