pypi和pip_Mozilla和PyPI-CSDN博客

pypi和pip

VM setup for kitsune

Kitsune的VM设置

The last time I wrote about PyPI some folks mistook the subject to be PyPy, so let me be clear: this article is about the Python Packaging Index.

我上一次写有关PyPI的文章时，有些人误以为是PyPy ，所以请让我清楚：这篇文章是关于Python Packaging Index的。

I recently began doing some volunteer work for Mozilla[1], working on a virtual machine setup to make kitsune development easier (kitsune is the code name for the Django site that powers support.mozilla.com).

我最近开始为Mozilla [1]做一些志愿工作，在虚拟机设置上进行工作，以简化kitsune的开发（kitsune是Django站点的代号，支持support.mozilla.com ）。

Git子模块 (Git submodules)

In doing so, I came across an interesting command from their installation docs:

为此，我从他们的安装文档中遇到了一个有趣的命令：

$ git submodule update --init --recursive
$ git submodule update --init --recursive

I can recall some vague rumblings about git submodules prior to this incident, but nothing I’d call “familiarity”. So, I shrugged it off and went about the business of creating the VM (and resisting the urge to use zc.buildout to do it):

我可以回想起在此事件之前关于git子模块的一些模糊的隆隆声，但是我什么也不会称之为“熟悉”。因此，我耸了耸肩，开始了创建VM的工作（并抵制了使用zc.buildout来完成它的冲动）：

On day 1, I created a VirtualBox VM using the latest Ubuntu Server and was able to assemble and run the application by following the instructions.
On day 2, I began to “vagrantize” the process. Here I ran into a bit of trouble with the git-submodule command[2]. This led me to seek alternative methods to install the various Python packages it was trying to install (when stuck on a problem I often like to pursue the alternatives immediately, so I have them if I need them.)

在第一天，我使用最新的Ubuntu Server创建了VirtualBox VM，并能够按照说明组装和运行该应用程序。
在第二天，我开始“证明”这一过程。在这里，我遇到了git-submodule命令[2]的麻烦。这导致我寻求替代方法来安装要尝试安装的各种Python软件包（当遇到问题时，我经常想立即寻求替代方法，因此如果需要，可以选择它们。）

赞博尼 (Zamboni)

Then, in the Mozilla IRC channel #sumodev (support mozilla) some nice Mozillian (willkg) pointed me to this gem:

然后，在Mozilla IRC频道#sumodev（ su pport mo zilla）中，一些不错的Mozillian（willkg）向我指出了这个宝石：

http://mozweb.readthedocs.org/en/latest/packaging.html

http://mozweb.readthedocs.org/en/latest/packaging.html

Which in turn led me to the following two links:

这又将我引向以下两个链接：

Again, faint rumblings… this time about zamboni (not THAT Zamboni). I know I’ve heard of it, but I wouldn’t call myself familiar with it. So, I innocently read the following:

再一次，微弱的隆隆声……这一次是关于zamboni（不是那个Zamboni）。我知道我听说过，但是我不会叫自己熟悉它。所以，我天真地读了以下内容：

Python projects can incur a number of dependencies. “pip“ can be handy, but we’ve had better luck with distributing a “vendor“ library.

Python项目可能会产生许多依赖关系。 “ pip”可能很方便，但是我们最好分发“ vendor”库。

At which point I immediately thought to myself:

这时我立即想到：

Yeah… I hear that. 是的...我听到了。

Followed a few seconds later by:

几秒钟后跟随：

Wait… what?!? 等等...什么？！？

Playdoh (Playdoh)

Some time/research later[3], I (re)discovered that zamboni is the codename for addons.mozilla.org[4]. And Playdoh is the code name for Mozilla’s base Django project setup. If you aren’t familiar with Playdoh, please do give it a whirl[5].

经过一段时间的研究[3]，我（重新）发现zamboni是addons.mozilla.org [4]的代号。 Playdoh是Mozilla基本Django项目设置的代号。如果您对Playdoh不熟悉，请尝试一下[5]。

聚酰亚胺 (PyPI)

While all of this is very, very interesting to me, I am primarily a “systems and processes” guy; and what ultimately stuck with me after two days of Mozilla-ing is the following blurb from the Playdoh packaging documentation:

尽管所有这些对我来说都非常有趣，但是我主要是一个“系统和流程”人。经过两天的Mozilla-ing最终困扰我的是Playdoh包装文档中的以下内容：

The “/vendor“ library is supposed to contain all packages and repositories. It enables the project to be deployed as one package onto many machines, without relying on PyPI-based installations on each target machine.

“ / vendor”库应该包含所有软件包和存储库。 它使项目可以作为一个程序包部署到多台计算机上，而无需依赖每台目标计算机上基于PyPI的安装。

“Nooooooooooooooo”, I am now saying to myself over and over. “Without relying on PyPI-based installations on each target machine.” Another “noooooooooooooooo!” I certainly don’t fault Mozilla for taking this approach, but it makes me sad that large organizations like Mozilla are passing over PyPI in favor of alternative methods of distributing Python software.

“ Nooooooooooooooooo”，我现在不断对自己说。 “无需依赖每台目标计算机上基于PyPI的安装。” 另一个“ noooooooooooooooooo！” 我当然不会指责Mozilla采用这种方法，但是令我感到遗憾的是，像Mozilla这样的大型组织正在通过PyPI来支持分发Python软件的替代方法。

Let us all now hang our heads, for a moment of pause and reflection.

现在让我们所有人都垂下来，稍作停顿和反思。

[a minute passes]

[一分钟过去]

未来 (The future)

I can’t speak for anyone else, but I would certainly like to see this change in the future. I would LOVE to see PyPI become a place that Mozilla felt confident it could use to deploy Python software. And this is something I’d love to work on for Mozilla, if given the opportunity[6].

我无法代表其他任何人说话，但我当然希望将来能看到这种变化。我很希望看到PyPI成为Mozilla确信可以用来部署Python软件的地方。如果有机会的话，我很乐意为Mozilla工作[6]。

非常适合Python ==非常适合Mozilla？ (Great for Python == great for Mozilla?)

It’s obvious what’s in it for Python, but what’s in for Mozilla?

很明显，Python中有什么功能，但是Mozilla中有什么功能呢？

Simple.

简单。

I happen to share Mozilla’s vision for an open web and open source in general. And it’s great to see them embracing & using Python for their web projects! Without a doubt, they are interested in giving back to the Python community (e.g. via Playdoh and the Django community, in this case.) So I suspect they’d be open to helping the Python community fix a long standing issue: the stability and reliability of the Python Package Index. It would certainly benefit them in the long run to simplify their build process to the point where git-submodule was no longer needed[7].

我碰巧分享了Mozilla对开放网络和开放源代码的总体看法。很高兴看到他们拥抱并在他们的Web项目中使用Python！毫无疑问，他们有兴趣回馈Python社区（在这种情况下，例如通过Playdoh和Django社区。）因此，我怀疑他们愿意帮助Python社区解决长期存在的问题：稳定性和稳定性。 Python包索引的可靠性。从长远来看，将它们的构建过程简化到不再需要git-submodule的地步，这肯定会给他们带来好处[7]。

笔记 (Notes)

[1] I am actively courting Mozilla in hopes of landing a gig by the end of the year. So all you Mozillians who know me personally, please put in a good word! And all you Mozillians I have not met yet: nice to meet you!

[1]我正在积极地向Mozilla求爱，希望能在今年年底前获得演出。因此，所有认识我的Mozillians都请您打个招呼！以及我尚未遇见的所有Mozillians：很高兴认识您！

[2] The problem turned out to be git-submodule failing to run because things like: grep and sed were missing from the PATH. Easily fixed by modifying the puppet configuration, but not easily discovered because git-submodule itself returned zero! Some guy on #puppet was very helpful in getting me to print out debug info.

[2]问题是git-submodule无法运行，因为PATH中缺少诸如grep和sed之类的东西。可以通过修改人偶配置轻松修复，但由于git-submodule本身返回零，因此不容易发现！ #puppet上的某个人对让我打印出调试信息非常有帮助。

[3] More help from friendly Mozillians in #webdev:

[3] #webdev中友善的Mozillians提供了更多帮助：

11:13 < groovecoder> aclark: yeah, zamboni is amo 11:13 < kumar> playdoh was extracted from zamboni and other apps 11:13 < kumar> but zamboni itself does not eat the playdoh dog food, actually 11:15 < kumar> aclark also, in case you’re not steeped in our initialisms, amo is addons.mozilla.org

11:13 <groovecoder> aclark：是的，zamboni是amo 11:13 <kumar> playdoh是从zamboni和其他应用程序中提取的11:13 <kumar>，但是zamboni本身不吃playdoh狗食，实际上11:15 <kumar >也可以使用aclark，以防万一您不习惯我们的缩写，amo是addons.mozilla.org

[4] There is a great presentation about it here: http://www.slideshare.net/andymckay/anatomy-of-a-large-django-site-7590098.)

[4]此处有一个很好的介绍： http : //www.slideshare.net/andymckay/anatomy-of-a-large-django-site-7590098 。）

[5] More from kumar (emphasis is my own):

[5]来自kumar的更多内容（强调是我自己的）：

Playdoh is starting to stabilize so it would be Playdoh开始稳定下来，因此很 good to see some use of it outside Mozilla; this would probably help us catch Mozilla-specific things that need extraction 高兴看到Mozilla之外有一些使用它 ；这可能会帮助我们捕获需要提取的Mozilla特定的东西

[6] LARGE HINT 😉

[6]大提示😉

[7] Again, not that there is anything wrong with what Mozilla is doing here. As a systems guy, I just happen to gravitate toward simplifying processes by eliminating steps.

[7]同样，这并不是Mozilla在这里所做的任何事情。作为系统人员，我只是倾向于通过消除步骤来简化流程。