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