为什么Python项目中没有用于自动化的Makefile? [英] Why are there no Makefiles for automation in Python projects?

问题描述

作为一个长期的Python程序员，我想知道，Python文化的中心方面是否让我困扰了很长时间:我们做什么而不是Makefile?

As a long time Python programmer, I wonder, if a central aspect of Python culture eluded me a long time: What do we do instead of Makefiles?

我见过的大多数红宝石项目(不仅仅是铁路项目)都使用 Rake ，在 node.js 流行之后不久，就有了 cake .在许多其他(已编译和未编译)语言中，都有经典的 Make 文件.

Most ruby-projects I've seen (not just rails) use Rake, shortly after node.js became popular, there was cake. In many other (compiled and non-compiled) languages there are classic Make files.

但是在Python中，似乎没有人需要这样的基础结构.我在GitHub上随机选择了Python项目，除了setup.py提供的安装之外，它们没有自动化.

But in Python, no one seems to need such infrastructure. I randomly picked Python projects on GitHub, and they had no automation, besides the installation, provided by setup.py.

这是什么原因?

没有什么可以自动化的吗?大多数程序员喜欢手动运行样式检查，测试等吗?

Is there nothing to automate? Do most programmers prefer to run style checks, tests, etc. manually?

一些例子:

• dependencies设置virtualenv并安装依赖项
• check调用pep8和pylint命令行工具.
• test任务取决于dependencies启用virtualenv，启动selenium-server进行集成测试，并调用nosetest
• coffeescript任务将所有咖啡脚本编译为精简的javascript
• runserver任务取决于dependencies和coffeescript
• deploy任务取决于check和test并部署项目.
• docs任务使用适当的参数调用sphinx

• dependencies sets up a virtualenv and installs the dependencies
• check calls the pep8 and pylint commandlinetools.
• the test task depends on dependencies enables the virtualenv, starts selenium-server for the integration tests, and calls nosetest
• the coffeescript task compiles all coffeescripts to minified javascript
• the runserver task depends on dependencies and coffeescript
• the deploy task depends on check and test and deploys the project.
• the docs task calls sphinx with the appropiate arguments

其中有些只是一线或两线，但恕我直言，它们加起来了.由于有了Makefile，我不必记住它们.

Some of them are just one or two-liners, but IMHO, they add up. Due to the Makefile, I don't have to remember them.

要澄清一下:我不是在寻找Rake的Python等效项.我为摊铺机感到高兴.我正在寻找原因.

To clarify: I'm not looking for a Python equivalent for Rake. I'm glad with paver. I'm looking for the reasons.

推荐答案

没有什么可以自动化的吗?

Is there nothing to automate?

并非如此.除了两个示例外，所有示例都是单行命令.

Not really. All but two of the examples are one-line commands.

tl; dr 其中很少有真正有趣或复杂的事情.这似乎很少受益于自动化".

tl;dr Very little of this is really interesting or complex. Very little of this seems to benefit from "automation".

由于文档的缘故，我不必记住执行此操作的命令.

Due to documentation, I don't have to remember the commands to do this.

大多数程序员喜欢手动运行样式检查，测试等吗?

Do most programmers prefer to run stylechecks, tests, etc. manually?

是的

生成文档， docs任务使用适当的参数调用sphinx

generation documentation, the docs task calls sphinx with the appropiate arguments

这是一行代码.自动化并没有太大帮助. sphinx-build -b html source build/html.那是个剧本.用Python编写.

It's one line of code. Automation doesn't help much. sphinx-build -b html source build/html. That's a script. Written in Python.

我们很少这样做.一周几次.在重大"更改之后.

We do this rarely. A few times a week. After "significant" changes.

运行样式检查(Pylint，Pyflakes和pep8-cmdtool). 检查调用pep8和pylint命令行工具

running stylechecks (Pylint, Pyflakes and the pep8-cmdtool). check calls the pep8 and pylint commandlinetools

我们不这样做.我们使用单元测试而不是pylint. 您可以使该三步过程自动化.

We don't do this. We use unit testing instead of pylint. You could automate that three-step process.

但是我可以看到SCons或make可以如何帮助这里的人.

测试

此处可能会有空间用于自动化".有两行:非Django单元测试(python test/main.py)和Django测试. (manage.py test).可以应用自动化来运行两条生产线.

There might be space for "automation" here. It's two lines: the non-Django unit tests (python test/main.py) and the Django tests. (manage.py test). Automation could be applied to run both lines.

我们每天要做数十次.我们从不知道我们需要自动化".

We do this dozens of times each day. We never knew we needed "automation".

依赖关系设置了virtualenv并安装了依赖关系

dependecies sets up a virtualenv and installs the dependencies

做得很少，以至于我们只需要一个简单的步骤列表.我们非常非常仔细地跟踪我们的依赖关系，因此不会有任何意外.

Done so rarely that a simple list of steps is all that we've ever needed. We track our dependencies very, very carefully, so there are never any surprises.

我们不这样做.

依赖于依赖项的测试任务启用了virtualenv，启动了用于集成测试的selenium-server，并调用了鼻子测试

the test task depends on dependencies enables the virtualenv, starts selenium-server for the integration tests, and calls nosetest

将start server & run nosetest分为两步的自动化"是有道理的.这样可以避免您输入两个Shell命令来运行两个步骤.

The start server & run nosetest as a two-step "automation" makes some sense. It saves you from entering the two shell commands to run both steps.

coffeescript任务将所有coffeescript编译为精简的javascript

the coffeescript task compiles all coffeescripts to minified javascript

这对我们来说是非常罕见的.我想这是要自动化的东西的一个很好的例子.单行脚本自动化可能会有所帮助.

This is something that's very rare for us. I suppose it's a good example of something to be automated. Automating the one-line script could be helpful.

我可以看到SCons或make如何帮助这里的人.

runserver任务取决于依赖关系和coffeescript

the runserver task depends on dependencies and coffeescript

除外.依赖关系变化很少，以至于看起来像是过分杀伤力.我想这可能是个好主意，因为您一开始就没有很好地跟踪依赖关系.

Except. The dependencies change so rarely, that this seems like overkill. I supposed it can be a good idea of you're not tracking dependencies well in the first place.

部署任务取决于检查和测试并部署项目.

the deploy task depends on check and test and deploys the project.

它是服务器上的svn co和python setup.py install，后面是一堆从Subversion区域到客户/www区域的特定于客户的副本.那是个剧本.用Python编写.

It's an svn co and python setup.py install on the server, followed by a bunch of customer-specific copies from the subversion area to the customer /www area. That's a script. Written in Python.

这不是一般品牌或SCons之类的东西.它只有一个参与者(一名系统管理员)和一个用例.我们永远不会将部署与其他开发，质量检查或测试任务混为一谈.

It's not a general make or SCons kind of thing. It has only one actor (a sysadmin) and one use case. We wouldn't ever mingle deployment with other development, QA or test tasks.

这篇关于为什么Python项目中没有用于自动化的Makefile?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！