pypi_捍卫PyPI

pypi

Everyone on the Python Planet is probably already familiar with Peter Fein’s recent article about PyPI.

Python Planet上的每个人都可能已经熟悉Peter Fein最近关于PyPI的文章。

Everyone on the Python Planet is probably already familiar with Peter Fein’s recent article about PyPI use (or lack thereof). But in case not, particularly striking was the number of folks who joined the “PyPI bashing” in the comments. In fact, it has inspired me to write this post “in defense of PyPI”. I would like to offer the Python community a summary of what I think are the general criticisms, along with my responses as a “sysadmin / developer type”.

Python Planet上的每个人都可能已经熟悉Peter Fein最近关于PyPI使用（或缺乏PyPI）的文章。 但是如果不是这样的话，在评论中加入“ PyPI扑朔迷离”的人数尤其惊人。 实际上，这启发了我写这篇文章“捍卫PyPI”。 我想向Python社区提供我认为是普遍批评的摘要，以及我对“系统管理员/开发人员类型”的回答。

First let me say this: I love PyPI! And I agree with Peter, if your package isn’t on PyPI it  “doesn’t exist”. I wouldn’t put it quite like that; but I would say it’s fairly important if you are publishing open source Python code, to consider uploading it to the Python Package Index.

首先让我这样说：我爱PyPI！ 我同意Peter的观点，如果您的软件包不在PyPI上，则“不存在”。 我不会这么说。 但是我要说的是，如果您要发布开源Python代码，则考虑将其上传到Python包索引中是非常重要的。

Why?

为什么？

因为每个人都赢 (Because Everybody Wins)

Believe it or not, the general Python community is interested in seeing your code. Whether to use it for an example, or to avoid reinventing the wheel, or whatever the reason; we’d like a chance to see your code. But if you don’t publish it to PyPI, we may never get that chance!

信不信由你，一般的Python社区都对查看您的代码感兴趣。 是将其用作示例，还是避免重新发明轮子，或出于任何原因； 我们希望有机会看到您的代码。 但是，如果您不将其发布到PyPI，我们可能永远也不会获得机会！

For better or worse, PyPI is the canonical place on Earth for Python packages. It’s the CPAN of Python. I understand that not everyone is 100% comfortable with this, but that doesn’t make it any less true. If you accept that “open source is good”, and that “Python rules”, then you simply must take this next leap of faith: “PyPI is the place for Python packages”.

不管是好是坏，PyPI是Python软件包在地球上的规范位置。 这是Python的CPAN。 我了解并非所有人都对此感到百分百满意，但这并没有使它不那么正确。 如果您接受“开源是好的”和“ Python规则”，那么您必须简单地迈出下一步的信念：“ PyPI是Python软件包的地方”。

[waves hand]

[挥手]

Moving on, why else should you consider uploading your packages to PyPI?

接下来，为什么还要考虑将软件包上传到PyPI？

因为这是要做的“正确”事情 (Because It Is The “Right” Thing To Do)

Another thing that struck me is the number of folks who (appear to) confuse “version control” with “distribution”. If I’m not mistaken, Launchpad, Github, and Bitbucket are primarily designed for Bazaar, Git, and Mercurial hosting respectively. These sites can host your distribution tarballs, but they certainly weren’t designed and built to do so. Rather, they were designed and built to host your source code.

使我震惊的另一件事是（似乎）使“版本控制”与“发行”相混淆的人们的数量。 如果我没记错的话，Launchpad，Github和Bitbucket主要是分别为Bazaar，Git和Mercurial托管设计的。 这些站点可以托管您的发行包，但是它们并不是经过精心设计和构建的。 相反，它们是为托管您的源代码而设计和构建的。

In some cases, a project may wish to host it’s own distribution server. Whether it be for redundancy (although PyPI has begun to tackle this) or “branding” or other reasons, I would argue this is the preferred way of handling it: in addition to uploading to PyPI, not in place of it.

在某些情况下，项目可能希望托管其自己的分发服务器 。 无论是出于冗余（尽管PyPI已开始解决此问题）还是出于“品牌效应”或其他原因，我都认为这是处理冗余的首选方式：除了上传到PyPI之外，还不能代替它。

Why?

为什么？

因为那并不难 (Because It Is Not That Hard)

Ahem… we get it. The situation with easy_install is “less than ideal”. But this is something to be fixed, not avoided. If you are receiving too many support requests, may I suggest simply telling people not to use easy_install. Or, if the problem is proper packaging, learn how to test your packages before uploading them. Due to the large number of screwed up releases I’ve made, I’ve come to rely on alocal PyPI and a virtualenv to test installations. Others use even simpler methods. And with tools like mkrelease, it’s easy to upload your package to multiple PyPI locations with just a single command (although leaping-tall-buildings-in-a single-bound is not yet supported.)

天哪...我们明白了。 easy_install的情况“不理想”。 但这是必须解决的，不能避免。 如果您收到太多的支持请求，我是否建议您简单地告诉人们不要使用easy_install 。 或者，如果问题是包装正确， 请在上传之前了解如何测试您的包装 。 由于我制作了很多乱七八糟的发行版，因此我不得不依靠本地PyPI和virtualenv来测试安装。 其他人甚至使用更简单的方法 。 借助mkrelease之类的工具，只需一个命令即可将软件包轻松上传到多个PyPI位置（尽管尚不支持将Jumping -Tall-Buildings 整合为一个绑定）。

The point is, please consider helping the community fix the problem rather than simply avoiding it. There are folks actively trying to improve the situation right now.

关键是，请考虑帮助社区解决问题，而不是简单地避免它。 现在有些人正在积极尝试改善这种状况 。

Let’s see, what else?

让我们看看，还有什么？

因为它不一定是完美的 (Because It Does Not Have To Be Perfect)

Over the years I’ve seen various and sundry criticisms of the PyPI user interface. Fine. I have not looked into the current development process, but I assume the author/maintainers would be open to some constructive criticism and/or development assistance.

多年来，我看到了对PyPI用户界面的各种批评。 精细。 我没有研究当前的开发过程，但是我认为作者/维护者会接受一些建设性的批评和/或发展援助。

It doesn’t have to be Github-sexy to be useful. If you would like to report a bug or feature request, do it here (at least, I think that is the right place.)

不一定需要Github-sexy才有用。 如果您想报告错误或功能请求，请在此处进行 （至少，我认为这是正确的位置。）

结论 (Conclusion)

I hope this convinces at least some folks to consider uploading their packages to PyPI. If it doesn’t, please let me know why in the comments.

我希望这能说服至少一些人考虑将其软件包上传到PyPI。 如果没有，请在评论中让我知道原因。

Did you enjoy reading this article? If so, please consider `helping me help Plone`_.

您喜欢阅读本文吗？ 如果是这样，请考虑“帮助我帮助Plone” _。

翻译自: https://www.pybloggers.com/2011/01/in-defense-of-pypi/

pypi