はじめにPythonで開発を行うにあたり、リンタやフォーマッタ、パッケージマネージャ等のツールの選定は非常に重要な問題です。一方で歴史的な経緯もあり、沢山の選択肢から何を選ぶべきか情報がまとまっていないように感じました。この記事では2021年9月時点でモダンと言えるであろう開発環境を紹介します。基本的にはシェアが高いこと、著名なパッケージで使用されていることを主な選定理由としており、また特定のエディタに依存しないことを前提とします。本記事で紹介する内容は一つのテンプレートに近く、必要に応じてカスタマイズするもよし、そのまま使ってもよし、として参考になればと思います。(CI/CDについてはPythonとは独立した問題なので触れません。ドキュメント生成はSphinxを推しますが、必須ではないので今回は割愛します。要約"モダン"な開発環境を箇条で列挙すると下記の通りです。以降、それぞれのツールについて触れます。2021年4月に不正アクセスを受けていたことを公表しています。便利かつ最新の仕様を反映しているツールを選定するがまず第一です。pyproject.tomlはPEP518にて定義された仕様で、より具体的には従来requirements.txtやsetup.pyといったファイルに散乱していた情報を一箇所に集めることができよりスマートになります。リポジトリのルートディレクトリはゴチャゴチャしがちなので、整理されていると嬉しいですよね。3.9Pythonの実装は様々ありますが、特に理由がなければオリジナルの実装であるCPython(誤解を恐れずに言えば"普通のPython")を使うのが無難でしょう。バージョンについては3.6系のサポートは2021-12-23にEoLを迎えるため、3.7系かそれより新しいバージョンを使用するべきです。加えて、パッケージの依存関係等で制約がない限りは基本的に新しいバージョンを使用することをおすすめします。3.10系が2021-10-04にリリース予定です。リリース直後は各種パッケージが未対応であることがあるため、しばらくは3.9系を使うのが無難かもしれません。(≠pyvenv)を使うことをおすすめします。※複数のPythonバージョンとパッケージの取り扱い、仮想環境についてはPEP582で議論されていますが、現時点ではまだDraftです。PoetrypoetryはNode.jsでいうところのnpmやyarn、rustでいうところのcargoに相当するパッケージマネージャの一つです。比較対象としてpipfileやrust製で後発のpyflowやが挙げられますが、現時点ではpoetryがよいでしょう。これらの比較については既に素敵な記事を書かれてる方がいらっしゃるので参考欄に記載します。blackblackは非常に制約の強いフォーマッタです。裏を返すとコードスタイルに幅がないがゆえにシンプルで、その分の考えるリソースを別の問題に割くことができます。多くの有名なライブラリにも採用されており、前述のpoetryや機械学習等で使われるpandasなども、blackによってフォーマットされています。blackを使用するにあたっては競合を避けるため、他のツール類に設定が必要な場合があります。本記事で紹介している組み合わせについては各項で取り上げますが、その他については参考欄に公式のDocリンクを貼ります。]についても合わせてご覧ください。isortisortは文字通りインポート周りをソート(フォーマット)してくれるツールです。blackはインポート文の順序までは規定がないため、isortと組み合わせて使うことでより快適になります。"black"として設定を行う必要があります。pflake8flake8は最も有名なリンタの一つです。唯一の難点は設定ファイル.flake8をpyproject.tomlに統合できないことです。議論(#issues/234)はされていますが、いくつかの理由で実現に至っていません。そこでflake8をラップしpyproject.tomlから設定を読むようにしたものがpflake8です。ここは好みが分かれる部分だと思いますが、本記事ではリポジトリのルートディレクトリの美しさを優先しました。Startsを見てオリジナルのflake8を選択するのも良いと思います。':'は無視する設定を行うことが推奨されています。flakehell)見受けられましたが、pyproject.tomlへの設定統合以上の追加機能も提供しており、一般的な開発には過剰と判断しました。flake8-bugbearそもそもflake8はコードのエラーチェック、PEP8の遵守チェック、循環的複雑度のチェックをまとめて行ってくれるツールです。これに加えてバグや問題が起きそうなところの警告を行うようにしてくれるのがflake8-bugbearです。適用したいルールは選択可能なので、一覧を眺めて選ぶもよし、とりあえず全部有効にするもよし、です。mypyPythonは型を明示することなくコーディングをすることが可能ですが、可読性や保守性を考えると型を明示するべきです。hintsを添えることの恩恵は大きいです。mypyは静的に型チェックを行うライブラリの一つで、最も古株、そしてベーシックです。checkerは現時点で事実上のデファクトスタンダードとなるものがないように思われ、恐らくその要因は用途や目的、そして使用するエディタによって使われているものが異なるためです。(web系ならpyre、vscode使いならpyrightを含む拡張であるpylance、など)本記事では最もベーシックかつ依存関係の小さいmypyを推奨としますが、参考まで下記に同様の機能を提供するライブラリとの簡潔な比較を記載します。pre-commitGitフックを管理するためのフレームワークがpre-commitです。.pre-commit-hooks.yamlというファイルに設定することで、commit時などにスクリプトが実行されます。スクリプトは自分で書くこともできますが、github上に公開されているものが数多くありますので、それらを指定することで簡単に様々なチクを設定できます。Hookの例を下記に示します。blackやflake8などのツール類もHookを提供していますので、コミット前にフォーマット、リンティングを自動で行うと安心です。基本的にはblackを使用することでPEP8を遵守することとなりますが、PEP8には一部モダンではない仕様が含まれています。blackも一行の長さ制限についてひとクセあるため明記します。119PEP8では一行の文字数は79文字以内と規定されています。これは諸説ありますが、1行が80文字のエディタ(ディスプレイ)を想定し、勝手に折り返されることを避けることが目的だとされています。hintsを書こうと思うとあまりに短すぎます。いくつに設定するのが良いのか?という問題の一つの答えが119です。Review機能で一行に表示される最大の文字数に由来します。(あまり発生しない事象ですが)blackは設定した一行の長さを守ろうと努力しますが、他のルールを破ってまでは守りません。lengthを10%超過したら初めて咎める、スピード違反的な取締り方式)を推奨しています。Review機能に追従して119文字と設定するなら、一文字でも長いと困るのでE501を使用するのが良いと思います。can’t”blackのドキュメントから引用ところで若干脱線しますが、blackのドキュメントでは視覚障害のある方は1行が100文字以上だと見にくいということが言及されています。W3Cのドキュメントにおいても視覚障害と一行の長さによる見やすさ(見にくさ)は言及されていますので、プロジェクトメンバに合わせて適切な値を設定すると良いと思います。開発環境のサンプル上記の環境を構成した状態のディレクトリと構築に要したコマンド、そしてpyproject.tomlのサンプルを以下に示します。