blocks|key|1967291|text|提出这一问题的原始PEP可以找到这里。远程已成为分发和安装Python模块的标准方法。|type|unstyled|depth|inlineStyleRanges|entityRanges|offset|length|data|1967292|为什么？恰好，python是一种很好的语言，可以用它来执行Python模块的安装。|1967293|entityMap|0|LINK|mutability|MUTABLE|url|http://www.python.org/dev/peps/pep-0229/^0|G|2|0|0|0^^$0|@$1|2|3|4|5|6|7|N|8|@]|9|@$A|O|B|P|1|Q]]|C|$]]|$1|D|3|E|5|6|7|R|8|@]|9|@]|C|$]]|$1|F|3|-4|5|6|7|S|8|@]|9|@]|C|$]]]|G|$H|$5|I|J|K|C|$L|M]]]]

The original PEP where this was raised can be found <a href="http://www.python.org/dev/peps/pep-0229/" rel="nofollow">here</a>. Distutils has become the standard method for distributing and installing Python modules.

Why? It just happens that python is a wonderful language to perform the installation of Python modules with.

blocks|key|1967330|text|没有什么可以自动化的吗？|type|blockquote|depth|inlineStyleRanges|entityRanges|data|1967331|不怎么有意思。除了两个示例之外，所有示例都是一行命令。|unstyled|1967332|博士博士很少有真正的有趣或复杂的事情。其中似乎很少能从“自动化”中受益。|offset|length|style|BOLD|1967333|由于文档的原因，我不需要记住执行此操作的命令。|1967334|大多数程序员更喜欢手工运行样式、测试等吗？|1967335|是。|1967336|生成文档时，docs任务使用批准的参数调用sphinx。|1967337|这是一行代码。自动化没有多大帮助。sphinx-build+-b+html+source+build/html。那是个剧本。用Python写的。|CODE|1967338|我们很少这样做。一周几次。在“重大”变化之后。|1967339|运行样式表(Pylint、Pyflake和pep8-cmdtool)。check调用pep8和pylint命令行工具|1967340|我们不会这么做的。我们使用单元测试而不是pylint。你可以让这三步过程自动化。|1967341|，但我能看出SCons或make如何帮助这里的人。|1967342|测试|1967343|这里可能有“自动化”的空间。它有两行:非Django单元测试(python+test/main.py)和Django测试。(manage.py+test)。自动化可以用于运行这两行。|1967344|我们每天都要这样做几十次。我们从来不知道我们需要“自动化”。|1967345|依赖方设置虚拟环境并安装依赖项。|1967346|很少这样做，所以我们所需要的只是一个简单的步骤列表。我们非常非常仔细地跟踪我们的依赖关系，因此不会有任何意外。|1967347|我们不会这么做的。|1967348|测试任务依赖于依赖关系，启用虚拟服务器，启动集成测试的selenium-server，并调用nosetest。|1967349|start+server+&+run+nosetest作为一个两步的“自动化”是有意义的。它可以避免输入两个shell命令来运行这两个步骤。|1967350|coffeescript任务将所有咖啡脚本编译为最小化的javascript|1967351|这对我们来说是非常罕见的。我想这是自动化的一个很好的例子。自动化一行脚本可能会有帮助。|1967352|我可以看到SCons或make如何帮助这里的人。|1967353|runserver任务依赖于依赖项和coffeescript。|1967354|除了。依赖性的变化如此之少，以至于这看起来太过分了。我认为这可能是一个很好的想法，你不是很好地跟踪依赖关系在第一。|1967355|部署任务依赖于检查和测试，并部署项目。|1967356|它是服务器上的svn+co和python+setup.py+install，然后是从subversion区域到customer+/www区域的一系列特定于客户的副本。那是个剧本。用Python写的。|1967357|这不是一般的制造或者SCons之类的东西。它只有一个参与者(系统管理员)和一个用例。我们永远不会将部署与其他开发、QA或测试任务混为一谈。|1967358|entityMap^0|0|0|0|2|0|0|0|0|0|H|12|0|0|0|0|0|P|0|0|V|J|1Q|E|0|0|0|0|0|0|0|R|0|0|0|0|O|0|0|0|0|7|6|E|N|1S|4|0|0^^$0|@$1|2|3|4|5|6|7|21|8|@]|9|@]|A|$]]|$1|B|3|C|5|D|7|22|8|@]|9|@]|A|$]]|$1|E|3|F|5|D|7|23|8|@$G|24|H|25|I|J]]|9|@]|A|$]]|$1|K|3|L|5|D|7|26|8|@]|9|@]|A|$]]|$1|M|3|N|5|6|7|27|8|@]|9|@]|A|$]]|$1|O|3|P|5|D|7|28|8|@]|9|@]|A|$]]|$1|Q|3|R|5|6|7|29|8|@]|9|@]|A|$]]|$1|S|3|T|5|D|7|2A|8|@$G|2B|H|2C|I|U]]|9|@]|A|$]]|$1|V|3|W|5|D|7|2D|8|@]|9|@]|A|$]]|$1|X|3|Y|5|6|7|2E|8|@]|9|@]|A|$]]|$1|Z|3|10|5|D|7|2F|8|@]|9|@]|A|$]]|$1|11|3|12|5|D|7|2G|8|@$G|2H|H|2I|I|J]]|9|@]|A|$]]|$1|13|3|14|5|6|7|2J|8|@]|9|@]|A|$]]|$1|15|3|16|5|D|7|2K|8|@$G|2L|H|2M|I|U]|$G|2N|H|2O|I|U]]|9|@]|A|$]]|$1|17|3|18|5|D|7|2P|8|@]|9|@]|A|$]]|$1|19|3|1A|5|6|7|2Q|8|@]|9|@]|A|$]]|$1|1B|3|1C|5|D|7|2R|8|@]|9|@]|A|$]]|$1|1D|3|1E|5|D|7|2S|8|@]|9|@]|A|$]]|$1|1F|3|1G|5|6|7|2T|8|@]|9|@]|A|$]]|$1|1H|3|1I|5|D|7|2U|8|@$G|2V|H|2W|I|U]]|9|@]|A|$]]|$1|1J|3|1K|5|6|7|2X|8|@]|9|@]|A|$]]|$1|1L|3|1M|5|D|7|2Y|8|@]|9|@]|A|$]]|$1|1N|3|1O|5|D|7|2Z|8|@$G|30|H|31|I|J]]|9|@]|A|$]]|$1|1P|3|1Q|5|6|7|32|8|@]|9|@]|A|$]]|$1|1R|3|1S|5|D|7|33|8|@]|9|@]|A|$]]|$1|1T|3|1U|5|6|7|34|8|@]|9|@]|A|$]]|$1|1V|3|1W|5|D|7|35|8|@$G|36|H|37|I|U]|$G|38|H|39|I|U]|$G|3A|H|3B|I|U]]|9|@]|A|$]]|$1|1X|3|1Y|5|D|7|3C|8|@]|9|@]|A|$]]|$1|1Z|3|-4|5|D|7|3D|8|@]|9|@]|A|$]]]|20|$]]

<blockquote>
 Is there nothing to automate? 
</blockquote>

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

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.

<blockquote>
 Do most programmers prefer to run stylechecks, tests, etc. manually?
</blockquote>

Yes.

<blockquote>
 generation documentation, 
 the docs task calls sphinx with the appropiate arguments
</blockquote>

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

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

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

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

But I can see how SCons or make might help someone here.

<blockquote>
 tests
</blockquote>

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

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

<blockquote>
 dependecies sets up a virtualenv and installs the dependencies
</blockquote>

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. 

We don't do this.

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

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

<blockquote>
 the coffeescript task compiles all coffeescripts to minified javascript
</blockquote>

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.

I can see how SCons or make might help someone here.

<blockquote>
 the runserver task depends on dependencies and coffeescript
</blockquote>

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.

<blockquote>
 the deploy task depends on check and test and deploys the project.
</blockquote>

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

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.

blocks|key|142527|text|任何优秀的测试工具都有一种在单个命令中运行整个套件的方法，没有什么能真正阻止您使用rake、make或其他任何东西。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|142528|没有什么理由发明一种新的方法，当现有的方法非常好的时候--为什么仅仅因为你没有发明就重新发明一些东西呢？(NIH)。|142529|entityMap^0|0|0^^$0|@$1|2|3|4|5|6|7|F|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|G|8|@]|9|@]|A|$]]|$1|D|3|-4|5|6|7|H|8|@]|9|@]|A|$]]]|E|$]]

Any decent test tool has a way of running the entire suite in a single command, and nothing is stopping you from using rake, make, or anything else, really.

There is little reason to invent a new way of doing things when existing methods work perfectly well - why re-invent something just because YOU didn't invent it? (NIH).

blocks|key|1967461|text|Python中有许多自动化选项。我不认为有一种反对自动化的文化，只是没有一种占主导地位的方法。公分母是双存根。|type|unstyled|depth|inlineStyleRanges|entityRanges|offset|length|data|1967462|与您的描述相近的是积木。这主要用于Zope/Plone世界。|1967463|我自己使用了以下几种组合：分发、pip和交换矩阵。我主要是使用Django进行开发，它为自动化命令提供了manage.py。|1967464|它也在Python+3.3中积极地工作。|1967465|entityMap|0|LINK|mutability|MUTABLE|url|http://docs.python.org/distutils/|1|http://www.buildout.org/|2|http://packages.python.org/distribute/|3|http://www.pip-installer.org/|4|http://docs.fabfile.org/|5|http://docs.python.org/dev/packaging/^0|1F|3|0|0|9|2|1|0|D|2|2|G|3|3|K|4|4|0|3|A|5|0^^$0|@$1|2|3|4|5|6|7|11|8|@]|9|@$A|12|B|13|1|14]]|C|$]]|$1|D|3|E|5|6|7|15|8|@]|9|@$A|16|B|17|1|18]]|C|$]]|$1|F|3|G|5|6|7|19|8|@]|9|@$A|1A|B|1B|1|1C]|$A|1D|B|1E|1|1F]|$A|1G|B|1H|1|1I]]|C|$]]|$1|H|3|I|5|6|7|1J|8|@]|9|@$A|1K|B|1L|1|1M]]|C|$]]|$1|J|3|-4|5|6|7|1N|8|@]|9|@]|C|$]]]|K|$L|$5|M|N|O|C|$P|Q]]|R|$5|M|N|O|C|$P|S]]|T|$5|M|N|O|C|$P|U]]|V|$5|M|N|O|C|$P|W]]|X|$5|M|N|O|C|$P|Y]]|Z|$5|M|N|O|C|$P|10]]]]

There is a number of options for automation in Python. I don't think there is a culture against automation, there is just not one dominant way of doing it. The common denominator is <a href="http://docs.python.org/distutils/" rel="noreferrer">distutils</a>.

The one which is closed to your description is <a href="http://www.buildout.org/" rel="noreferrer">buildout</a>. This is mostly used in the Zope/Plone world.

I myself use a combination of the following: <a href="http://packages.python.org/distribute/" rel="noreferrer">Distribute</a>, <a href="http://www.pip-installer.org/" rel="noreferrer">pip</a> and <a href="http://docs.fabfile.org/" rel="noreferrer">Fabric</a>. I am mostly developing using Django that has manage.py for automation commands.

It is also being actively worked on in <a href="http://docs.python.org/dev/packaging/" rel="noreferrer">Python 3.3</a>

blocks|key|142621|text|Setuptools可以自动完成很多事情，对于没有内置的东西，它很容易扩展。|type|unstyled|depth|inlineStyleRanges|offset|length|style|CODE|entityRanges|data|142622|要运行单元测试，可以在向setup.py+test调用中添加test_suite参数之后使用setup()命令。(文档)|unordered-list-item|142623|依赖项(即使在PyPI上不可用)可以通过向setup()调用添加一个setup()参数来处理。(文档)|142624|要创建.deb包，可以使用stdeb模块。|142625|对于其他一切，您可以使用添加自定义setup.py命令。|142626|但我同意S.Lott的观点，大多数您希望自动化的任务(除了依赖关系处理，这是我发现的唯一真正有用的任务)都是您不每天运行的任务，因此自动化它们不会真正提高生产力。|142627|entityMap|0|LINK|mutability|MUTABLE|url|https://setuptools.readthedocs.io/en/latest/|1|http://setuptools.readthedocs.io/en/latest/setuptools.html#test-build-package-and-run-a-unittest-suite|2|http://setuptools.readthedocs.io/en/latest/setuptools.html#declaring-dependencies|3|http://pypi.python.org/pypi/stdeb#sdist-dsc-distutils-command|4|http://setuptools.readthedocs.io/en/latest/setuptools.html#extending-and-reusing-setuptools^0|0|A|0|A|0|0|C|D|U|A|1A|7|1L|2|1|0|L|7|Y|7|1C|2|2|0|3|4|D|5|D|5|3|0|C|F|4|0|4|6|0^^$0|@$1|2|3|4|5|6|7|16|8|@$9|17|A|18|B|C]]|D|@$9|19|A|1A|1|1B]]|E|$]]|$1|F|3|G|5|H|7|1C|8|@$9|1D|A|1E|B|C]|$9|1F|A|1G|B|C]|$9|1H|A|1I|B|C]]|D|@$9|1J|A|1K|1|1L]]|E|$]]|$1|I|3|J|5|H|7|1M|8|@$9|1N|A|1O|B|C]|$9|1P|A|1Q|B|C]]|D|@$9|1R|A|1S|1|1T]]|E|$]]|$1|K|3|L|5|H|7|1U|8|@$9|1V|A|1W|B|C]|$9|1X|A|1Y|B|C]]|D|@$9|1Z|A|20|1|21]]|E|$]]|$1|M|3|N|5|H|7|22|8|@]|D|@$9|23|A|24|1|25]]|E|$]]|$1|O|3|P|5|6|7|26|8|@$9|27|A|28|B|C]]|D|@]|E|$]]|$1|Q|3|-4|5|6|7|29|8|@]|D|@]|E|$]]]|R|$S|$5|T|U|V|E|$W|X]]|Y|$5|T|U|V|E|$W|Z]]|10|$5|T|U|V|E|$W|11]]|12|$5|T|U|V|E|$W|13]]|14|$5|T|U|V|E|$W|15]]]]

<a href="https://setuptools.readthedocs.io/en/latest/" rel="nofollow noreferrer"><code>Setuptools</code></a> can automate a lot of things, and for things that aren't built-in, it's easily extensible.

<ul>
<li>To run unittests, you can use the <code>setup.py test</code> command after having added a <code>test_suite</code> argument to the <code>setup()</code> call. (<a href="http://setuptools.readthedocs.io/en/latest/setuptools.html#test-build-package-and-run-a-unittest-suite" rel="nofollow noreferrer">documentation</a>)</li>
<li>Dependencies (even if not available on PyPI) can be handled by adding a <code>install_requires</code>/<code>extras_require</code>/<code>dependency_links</code> argument to the <code>setup()</code> call. (<a href="http://setuptools.readthedocs.io/en/latest/setuptools.html#declaring-dependencies" rel="nofollow noreferrer">documentation</a>)</li>
<li>To create a <code>.deb</code> package, you can use the <a href="http://pypi.python.org/pypi/stdeb#sdist-dsc-distutils-command" rel="nofollow noreferrer"><code>stdeb</code></a> module.</li>
<li>For everything else, you can <a href="http://setuptools.readthedocs.io/en/latest/setuptools.html#extending-and-reusing-setuptools" rel="nofollow noreferrer">add custom setup.py commands</a>.</li>
</ul>

But I agree with <code>S.Lott</code>, most of the tasks you'd wish to automate (except dependencies handling maybe, it's the only one I find really useful) are tasks you don't run everyday, so there wouldn't be any real productivity improvement by automating them.

blocks|key|1967513|text|实际上，自动化对Python开发人员也很有用！|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1967514|Invoke可能是您所想到的最接近的工具，用于常见的重复Python任务的自动化：https://github.com/pyinvoke/invoke。|offset|length|1967515|使用invoke，您可以创建类似于此的tasks.py+(从调用文档借用)|1967516|from+invoke+import+run,+task

@task
def+clean(docs=False,+bytecode=False,+extra=''):
++++patterns+=+['build']
++++if+docs:
++++++++patterns.append('docs/_build')
++++if+bytecode:
++++++++patterns.append('**/*.pyc')
++++if+extra:
++++++++patterns.append(extra)
++++for+pattern+in+patterns:
++++++++run("rm+-rf+%25s"+%25+pattern)

@task
def+build(docs=False):
++++run("python+setup.py+build")
++++if+docs:
++++++++run("sphinx-build+docs+docs/_build")|code-block|syntax|javascript|1967517|然后可以在命令行运行这些任务，例如：|1967518|$+invoke+clean
$+invoke+build+--docs|1967519|另一个选择是简单地使用Makefile。例如，Python项目的Makefile可能如下所示：|1967520|docs:
++++$(MAKE)+-C+docs+clean
++++$(MAKE)+-C+docs+html
++++open+docs/_build/html/index.html

release:+clean
++++python+setup.py+sdist+upload

sdist:+clean
++++python+setup.py+sdist
++++ls+-l+dist|1967521|entityMap|0|LINK|mutability|MUTABLE|url|https://github.com/pyinvoke/invoke^0|0|15|Y|0|0|0|0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|12|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|13|8|@]|9|@$D|14|E|15|1|16]]|A|$]]|$1|F|3|G|5|6|7|17|8|@]|9|@]|A|$]]|$1|H|3|I|5|J|7|18|8|@]|9|@]|A|$K|L]]|$1|M|3|N|5|6|7|19|8|@]|9|@]|A|$]]|$1|O|3|P|5|J|7|1A|8|@]|9|@]|A|$K|L]]|$1|Q|3|R|5|6|7|1B|8|@]|9|@]|A|$]]|$1|S|3|T|5|J|7|1C|8|@]|9|@]|A|$K|L]]|$1|U|3|-4|5|6|7|1D|8|@]|9|@]|A|$]]]|V|$W|$5|X|Y|Z|A|$10|11]]]]

Actually, automation is useful to Python developers too!

Invoke is probably the closest tool to what you have in mind, for automation of common repetitive Python tasks: <a href="https://github.com/pyinvoke/invoke">https://github.com/pyinvoke/invoke</a>

With invoke, you can create a tasks.py like this one (borrowed from the invoke docs)

<pre><code>from invoke import run, task

@task
def clean(docs=False, bytecode=False, extra=''):
 patterns = ['build']
 if docs:
 patterns.append('docs/_build')
 if bytecode:
 patterns.append('**/*.pyc')
 if extra:
 patterns.append(extra)
 for pattern in patterns:
 run("rm -rf %s" % pattern)

@task
def build(docs=False):
 run("python setup.py build")
 if docs:
 run("sphinx-build docs docs/_build")
</code></pre>

You can then run the tasks at the command line, for example:

<pre><code>$ invoke clean
$ invoke build --docs
</code></pre>

Another option is to simply use a Makefile. For example, a Python project's Makefile could look like this:

<pre><code>docs:
 $(MAKE) -C docs clean
 $(MAKE) -C docs html
 open docs/_build/html/index.html

release: clean
 python setup.py sdist upload

sdist: clean
 python setup.py sdist
 ls -l dist
</code></pre>

blocks|key|59584|text|make实用工具是一种优化工具，它可以减少构建软件映像所花费的时间。当以前的版本中的所有中间材料仍然可用时，只对输入(例如源代码)进行了小的更改，就可以缩短时间。在这种情况下，make能够执行“增量构建”：仅重建受输入更改影响的中间部分的子集。|type|unstyled|depth|inlineStyleRanges|offset|length|style|CODE|entityRanges|data|59585|当一个完整的构建发生时，make实际上所做的就是执行一组脚本步骤。这些相同的步骤可以直接存放到一个平面脚本中。实际上，-n选项make将打印这些步骤，这使得这成为可能。|59586|Makefile不是“自动化”，而是“着眼于优化增量重建的自动化”。任何用脚本工具编写的脚本都是自动化的。|59587|那么，为什么Python项目要回避像make这样的工具呢？可能是因为Python项目并没有为他们渴望优化的长构建时间而挣扎。而且，将.py编译为.pyc文件并不具有与.c到.o相同的依赖网络。|59588|C源文件可以#include数百个依赖的文件；其中任何一个文件中的一个字符的更改都可能意味着必须重新编译源文件。正确编写的Makefile将检测是否是这样的情况。|59589|没有增量构建系统的大型C或C%2B%2B项目意味着开发人员必须等待数小时才能弹出可执行映像以进行测试。快速的增量构建是必不可少的。|59590|在Python的例子中，您可能需要担心的是，当.py文件比其对应的.pyc更新时，可以通过简单的脚本处理:遍历所有文件，并重新编译任何更新的字节代码。此外，编译首先是可选的！|59591|所以projects之所以不使用make，是因为它们执行增量重建优化的需求很低，而且它们使用其他工具实现自动化；Python程序员更熟悉的工具，比如Python本身。|59592|entityMap^0|0|4|2G|4|0|C|4|1N|2|1R|4|0|0|I|4|1U|3|20|4|2B|2|2E|2|0|6|8|1P|8|0|0|N|3|X|4|0|G|4|0^^$0|@$1|2|3|4|5|6|7|V|8|@$9|W|A|X|B|C]|$9|Y|A|Z|B|C]]|D|@]|E|$]]|$1|F|3|G|5|6|7|10|8|@$9|11|A|12|B|C]|$9|13|A|14|B|C]|$9|15|A|16|B|C]]|D|@]|E|$]]|$1|H|3|I|5|6|7|17|8|@]|D|@]|E|$]]|$1|J|3|K|5|6|7|18|8|@$9|19|A|1A|B|C]|$9|1B|A|1C|B|C]|$9|1D|A|1E|B|C]|$9|1F|A|1G|B|C]|$9|1H|A|1I|B|C]]|D|@]|E|$]]|$1|L|3|M|5|6|7|1J|8|@$9|1K|A|1L|B|C]|$9|1M|A|1N|B|C]]|D|@]|E|$]]|$1|N|3|O|5|6|7|1O|8|@]|D|@]|E|$]]|$1|P|3|Q|5|6|7|1P|8|@$9|1Q|A|1R|B|C]|$9|1S|A|1T|B|C]]|D|@]|E|$]]|$1|R|3|S|5|6|7|1U|8|@$9|1V|A|1W|B|C]]|D|@]|E|$]]|$1|T|3|-4|5|6|7|1X|8|@]|D|@]|E|$]]]|U|$]]

The <code>make</code> utility is an optimization tool which reduces the time spent building a software image. The reduction in time is obtained when all of the intermediate materials from a previous build are still available, and only a small change has been made to the inputs (such as source code). In this situation, <code>make</code> is able to perform an "incremental build": rebuild only a subset of the intermediate pieces that are impacted by the change to the inputs.

When a complete build takes place, all that <code>make</code> effectively does is to execute a set of scripting steps. These same steps could just be deposited into a flat script. The <code>-n</code> option of <code>make</code> will in fact print these steps, which makes this possible.

A Makefile isn't "automation"; it's "automation with a view toward optimized incremental rebuilds." Anything scripted with any scripting tool is automation.

So, why would Python project eschew tools like <code>make</code>? Probably because Python projects don't struggle with long build times that they are eager to optimize. And, also, the compilation of a <code>.py</code> to a <code>.pyc</code> file does not have the same web of dependencies like a <code>.c</code> to a <code>.o</code>.

A C source file can <code>#include</code> hundreds of dependent files; a one-character change in any one of these files can mean that the source file must be recompiled. A properly written <code>Makefile</code> will detect when that is or is not the case.

A big C or C++ project without an incremental build system would mean that a developer has to wait hours for an executable image to pop out for testing. Fast, incremental builds are essential.

In the case of Python, probably all you have to worry about is when a <code>.py</code> file is newer than its corresponding <code>.pyc</code>, which can be handled by simple scripting: loop over all the files, and recompile anything newer than its byte code. Moreover, compilation is optional in the first place!

So the reason Python projects tend not to use <code>make</code> is that their need to perform incremental rebuild optimization is low, and they use other tools for automation; tools that are more familiar to Python programmers, like Python itself.

blocks|key|1967564|text|下面是用python使用makefile的几个例子：|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1967565|https://blog.horejsek.com/makefile-with-python/|offset|length|1967566|https://krzysztofzuraw.com/blog/2016/makefiles-in-python-projects.html|1967567|我认为大多数人都不知道"makefile+for+python“的情况。这可能是有用的，但“性别比”太小，无法迅速传播(只是我的PPOV)。|1967568|entityMap|0|LINK|mutability|MUTABLE|url|1^0|0|0|1B|0|0|0|1Y|1|0|0^^$0|@$1|2|3|4|5|6|7|R|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|S|8|@]|9|@$D|T|E|U|1|V]]|A|$]]|$1|F|3|G|5|6|7|W|8|@]|9|@$D|X|E|Y|1|Z]]|A|$]]|$1|H|3|I|5|6|7|10|8|@]|9|@]|A|$]]|$1|J|3|-4|5|6|7|11|8|@]|9|@]|A|$]]]|K|$L|$5|M|N|O|A|$P|C]]|Q|$5|M|N|O|A|$P|G]]]]

Here are few examples of makefile usage with python:

<a href="https://blog.horejsek.com/makefile-with-python/" rel="nofollow noreferrer">https://blog.horejsek.com/makefile-with-python/</a>

<a href="https://krzysztofzuraw.com/blog/2016/makefiles-in-python-projects.html" rel="nofollow noreferrer">https://krzysztofzuraw.com/blog/2016/makefiles-in-python-projects.html</a>

I think that a most of people is not aware "makefile for python" case. It could be useful, but "sexiness ratio" is too small to propagate rapidly (just my PPOV).

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?

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.

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 <code>setup.py</code>.

What's the reason behind this?

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

Some examples:

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

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.

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

Why are there no Makefiles for automation in Python projects?

翻译质量差，导致语言生硬或混乱。

没有提供实际的解决方法或示例。

解答不清晰，无法理解或解决问题。

页面排版不美观，阅读体验差。

文章

问答

视频

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

作为一个长期从事Python编程的程序员，我想知道，Python文化的一个核心方面是否很长一段时间没有实现:我们应该做什么而不是Makefiles呢？我见过的大多数红宝石项目(不仅仅是Rake)都使用Rake，在node.js流行后不久，就有了蛋糕。在许多其他语言(编译和非编译)中，有经典的Make。但是在Python...

问为什么Python项目中没有用于自动化的Makefiles？
EN

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问为什么Python项目中没有用于自动化的Makefiles？EN

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问为什么Python项目中没有用于自动化的Makefiles？
EN