長い間Pythonプログラマーとして、Python文化の中心的な側面が私を長い間逃してきたのではないかと思います:Makefileの代わりに何をしますか?
私が見たほとんどのRubyプロジェクト(Railsだけでなく)はRakeを使用し、node.jsが普及した直後にケーキ。他の多くの(コンパイル済みおよび非コンパイル済み)言語には、クラシックMakeファイルがあります。
しかし、Pythonでは、そのようなインフラストラクチャを必要とする人はいないようです。私はランダムにGitHubでPythonプロジェクトを選びましたが、インストール以外にsetup.py
によって提供される自動化はありませんでした。
この背後にある理由は何ですか?
自動化するものはありませんか?ほとんどのプログラマーは、スタイルチェックやテストなどを手動で実行することを好みますか?
いくつかの例:
dependencies
virtualenvをセットアップし、依存関係をインストールしますcheck
はpep8
およびpylint
コマンドラインツールを呼び出します。test
タスクはdependencies
に依存し、virtualenvを有効にし、統合テストのためにSeleniumサーバーを起動し、nosetest
を呼び出します。coffeescript
タスクは、すべてのコーヒースクリプトを縮小されたJavaScriptにコンパイルしますrunserver
タスクはdependencies
とcoffeescript
に依存しますdeploy
タスクはcheck
とtest
に依存し、プロジェクトをデプロイします。docs
タスクは、適切な引数を使用してsphinxを呼び出しますそれらのいくつかは1つまたは2つのライナーですが、私見では、それらは合計されます。 Makefileがあるので、覚えておく必要はありません。
明確にするために:私はRakeに相当するPythonを探していません。ペーバーに満足しています。理由を探しています。
実際、自動化はPython開発者にとっても便利です!
一般的な反復Pythonタスク: https://github.com/pyinvoke/invoke )を自動化するために、Invokeはおそらくあなたが考えているものに最も近いツールです。
Invokeを使用すると、次のようなtasks.pyを作成できます(invokeドキュメントから借用)
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")
次に、コマンドラインでタスクを実行できます。次に例を示します。
$ invoke clean
$ invoke build --docs
別のオプションは、単にMakefileを使用することです。たとえば、PythonプロジェクトのMakefileは次のようになります:
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
Setuptools
は多くのことを自動化でき、組み込みではないものについては簡単に拡張できます。
setup()
呼び出しに_setup.py test
_引数を追加した後、_test_suite
_コマンドを使用できます。 ( ドキュメント )setup()
呼び出しに_install_requires
_/_extras_require
_/_dependency_links
_引数を追加することで処理できます。 ( ドキュメント ).deb
_パッケージを作成するには、 stdeb
モジュールを使用できます。しかし、私は_S.Lott
_に同意します。自動化したいタスクのほとんど(依存関係の処理を除いて、私が本当に役立つと思うのはそれだけです)は、毎日実行しないタスクなので、ありません。それらを自動化することによる実際の生産性の向上。
適切なテストツールには、スイート全体を1つのコマンドで実行する方法があり、rake、make、またはその他のものを実際に使用することを妨げるものは何もありません。
既存の方法が完全にうまく機能するときに、物事を行うための新しい方法を発明する理由はほとんどありません-なぜあなたがそれを発明しなかったという理由だけで何かを再発明するのですか? (NIH(アメリカ国立衛生研究所)(#文字数制限がない場合、初出時にかっこ書きを追加)。
これが発生した元のPEPは、 ここ にあります。 Distutilsは、Pythonモジュールを配布およびインストールするための標準的な方法になりました。
どうして? pythonは、Pythonモジュールのインストールを実行するのに最適な言語です。
make
ユーティリティは、ソフトウェアイメージの構築にかかる時間を短縮する最適化ツールです。時間の短縮は、前のビルドのすべての中間マテリアルがまだ利用可能であり、入力(ソースコードなど)にわずかな変更が加えられた場合に得られます。この状況では、make
は「インクリメンタルビルド」を実行できます。つまり、入力の変更によって影響を受ける中間部分のサブセットのみを再構築します。
完全なビルドが行われると、make
が効果的に行うのは、一連のスクリプトステップを実行することだけです。これらの同じ手順は、フラットなスクリプトにまとめることができます。 make
の-n
オプションは、実際にはこれらのステップを出力します。これにより、これが可能になります。
Makefileは「自動化」ではありません。それは「最適化されたインクリメンタル再構築を視野に入れた自動化」です。スクリプトツールでスクリプト化されたものはすべて自動化です。
では、なぜPythonプロジェクトはmake
のようなツールを避けますか?おそらくPythonプロジェクトは、熱心な長いビルド時間に苦労しないからですまた、.py
から.pyc
ファイルへのコンパイルには、.c
から.o
への依存関係の同じウェブがありません。
Cソースファイルは、何百もの依存ファイルを#include
できます。これらのファイルのいずれかが1文字変更された場合は、ソースファイルを再コンパイルする必要があることを意味します。適切に記述されたMakefile
は、そうであるかどうかを検出します。
インクリメンタルビルドシステムのない大きなCまたはC++プロジェクトは、開発者がテストのために実行可能イメージがポップアウトするのを待つ必要があることを意味します時間。高速でインクリメンタルなビルドが不可欠です。
Pythonの場合、おそらく心配する必要があるのは、.py
ファイルが対応する.pyc
よりも新しい場合です。これは、単純なスクリプトで処理できます。すべてのファイルをループし、すべてを再コンパイルします。そのバイトコードよりも新しい。また、そもそもコンパイルはオプションです!
したがって、Pythonプロジェクトがmake
を使用しない傾向がある理由は、増分再構築の最適化を実行する必要性が低く、自動化のために他のツールを使用しているためです。 Pythonプログラマー、Python自体のように。
Pythonでのmakefileの使用例をいくつか示します。
https://blog.horejsek.com/makefile-with-python/
https://krzysztofzuraw.com/blog/2016/makefiles-in-python-projects.html
ほとんどの人は「Python用のmakefile」の場合を知らないと思います。役に立つかもしれませんが、「セクシーさの比率」は小さすぎて急速に伝播できません(私のPPOVだけです)。