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 <[email protected] (mailto:[email protected])> > 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: > > http://mail.python.org/pipermail/catalog-sig/2011-May/003746.html > > > 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 > [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
