Hi
On 2/6/12 11:15 AM, Daniel Greenfeld wrote:
On Mon, Feb 6, 2012 at 7:32 AM, Martijn Faassen<[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. 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] to
install any packages released to 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 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]
http://mail.python.org/mailman/listinfo/catalog-sig
