Stimulator

機械学習とか好きな技術話とかエンジニア的な話とかを書く

pipとpipenvとpoetryの技術的・歴史的背景とその展望

- はじめに -

Pythonのパッケージ管理ツールは、長らく乱世にあると言える。

特にpip、pipenv、poetryというツールの登場シーン前後では、多くの変革がもたらされた。

本記事は、Pythonパッケージ管理ツールであるpip、pipenv、poetryの3つに着目し、それぞれのツールに対してフラットな背景、技術的な説明を示しながら、所属企業内にてpoetry移行大臣として1年活動した上での経験、移行の意図について綴り、今後のPythonパッケージ管理の展望について妄想するものである。

注意:本記事はPythonパッケージ管理のベストプラクティスを主張する記事ではありません。背景を理解し自らの開発環境や状態に応じて適切に技術選定できるソフトウェアエンジニアこそ良いソフトウェアエンジニアであると筆者は考えています。

重要なポイントのみ把握したい場合は、各章の最後のまとめを読んで頂ければと思います

 


 

- Pythonのパッケージ管理ツール概論 -

まずはじめに、2020年3月現在、主に「Python パッケージ管理」等のワードでググると出てくる3つの大きなツール、pip、pipenv、poetryについて概論的に説明する。

最も表面的な概要だけ把握するために、私が社内向けに作成した資料を以下に引用する。

f:id:vaaaaaanquish:20210321112826p:plain
社内LT向けに作成した資料より加筆の上抜粋

多くは後述するが、ここでスライドが主張している重要な点を文字におこしておくと以下のようになる。

  • pipenvはPyPAが開発しているツールで同じくPyPAが開発するpipの機能を補っている
  • pipenvとpoetryの大きな"機能"の違いはパッケージのbuild・publishをサポートしているかどうか
  • pipenv、poetry以外に他にも多くのパッケージ管理ツールが存在する

本記事のタイトルを解消する上で重要な点は上2つであり、これらについてpip、pipenv、poetryの概要を示しながら本章で触れていく。本記事においては、Anacondaや他ツールについては本筋ではないため、本章の最後に簡単にまとめて触れる。

pip

pipは、最も基本的なPythonのパッケージ管理ツール、より正確にはパッケージインストーラである。PyPI*1より、Pythonモジュールをインストールするためのツールであり、Pythonの拡充提案、プロセス、設計、標準を決める文書群であるPEP内の、PEP 453によって、Pythonが公式にサポートするツールとなっている。Python3.4からは、Pythonに内包されデフォルトでインストールされる。
github.com


パッケージ管理の側面から見た場合は、以下のようなrequirements.txtというファイルを記述し、そのファイルで利用するモジュールのバージョンを管理する形式を取る。

numpy<=1.0.0
pandas==1.1.5
jupyterlab>=2.0.0
...

pipは具体的に依存treeを生成するような依存解決は行わず、順番にインストールしていき、サブモジュールの依存関係に問題があった場合は上書きする事で解決する。上記であればpandasやjupyter labによってnumpyはバージョンアップしたものが入る事になる。

pipと後述するpipenvの関係において、上記を背景とし一般的なプログラミング言語がプロダクト開発でそれを必要とするのと同様に「依存関係を解決する」「lockファイルを生成しサブモジュールを含む全てのモジュールバージョンをhashで管理する」事が求められた結果pipenvが開発された、という認識は間違いではない。実際、上記のrequirements.txtだけではパッケージングを行う事は出来ない事は想像できるだろう。
長らくユーザはsetup.pyやsetup.cfgを書き、PyPAが別途作成するwheelsetuptoolsといったツールでパッケージング、また別途PyPAが作成するtwinを用いてパッケージレジストリであるPyPIにアップロードするというライフサイクルに倣っており、バージョン固定や開発環境管理は各ユーザに委ねられていた。pipenvやそれら以外のツールについて具体的には後述するが、pip自体が手続き的なバージョン管理方法やパッケージングの方法を持っていないが故に、別ツールとしてパッケージングツールが作られていった結果として、今多くのパッケージング管理関連ツールが生まれ続けるPythonの環境になっているとも言える*2

 
2021年においては、パッケージ管理の側面で、上記の前提に加えてpipの2つの大きな変更を把握しておく必要がある。それがpyproject.tomlと2020-resolverである。

 

pyproject.toml (PEP 518)

1つ目に、PEP 518で制定されたpyptoject.tomlというフォーマットがある。後述のpoetryで利用されている事は広く知られているが、pipもまたpyproject.toml対応しているという点が重要になる。

pyptoject.tomlは、以下のような単一のtomlファイルをrequirements.txtやそれらを参照するsetup.pyの代替とする事が出来るようになっている*3

[install_requires]
pandas = "*"

[build-system]
requires = ["setuptools", "wheel", "toml"]

これはpip単体では大きな旨味はないが、pyproject.tomlが単一のファイルでパッケージのメタデータや依存ライブラリ、フォーマッタやenv環境、buildの設定を記述できる事を踏まえ、後述のpoetryのようなPEP 518対応のパッケージングツールと組み合わせる事で、ファイル及びツールを小さく集約する事が可能になっている*4

かなり簡単に言えば、これだけ書いとけば開発関連の設定はオールオッケーなsettings.tomlである。

pyproject.tomlについてより詳しくは後述するが、現在最も注目される仕様の1つであり、把握しておくと良い。

 

2020-resolver

pipにおける重要な変更として、2つ目に、現在テスト段階にある依存解決を行うリゾルバ、2020-resolverのリリースがある。

先述の通り、pipは強い依存解決を行わないツールだった。故にpip単体では、依存モジュールのバージョンの違いと、それらのインストールの前後関係によって問題が発生してしまう*5。対して2020-resolverは、シンプルなbacktrackingを利用した依存解決リゾルバであり、強い依存解決を事前に行う事で、pipのインストールの前後関係による課題を解消するものである。

リリースブログより各リンクを追う形で、多くの議論が追える。
pyfound.blogspot.com
 
 

さて、ここで本記事で最も重要な比較の話をするため、依存解決というテーマに触れておく。

多くのパッケージ管理ツールが行う重要な機能の1つに依存解決がある。パッケージの依存解決を行うリゾルバ(resolver)が、非常に難しい問題に挑んでいる事は、dependency hellという言葉と共によく知られている通りである。

en.wikipedia.org

依存解決リゾルバのアルゴリズムでは、SAT*6における教科書的なbacktrackingアルゴリズム*7を利用した解決方法が知られている*8。有名所では、RubyのBundlerが依存解決のために利用しているMolinilloというライブラリがそのresolverのbacktrackingロジックを持っていたり、RustにおけるCargoのコアロジックにあたるrust-semverでもDFS(深さ優先探索)とbacktrackingが利用されている。言語系の依存解決リゾルバが〜〜〜という話ではなくOpenSUSEのLibzyppでもminiSATベースのライブラリであるlibsolvが利用されている。
 
また、近年では2018年にGoogleのNatalie Weizenbaum(@nex3)Dartのパッケージ管理ツールのために提案したPubGrub*9というアルゴリズムが話題になっている。PubGrubは、backtrackingの拡張アルゴリズムであり*10、非互換性のあるパッケージを見つけた時に効率的に探索を行うUnit Propagation*11を組み合わせる形で実現されている。PubGrubは効率的かつ解釈可能な非互換性を見つけられる点でより優れたロジックで、SwiftPMにマージされていたり、先に登場したCargo内でも議論があったり、RubyにもPubGrubベースのgel-rbという新しいパッケージ管理ツールが出てきていたり、Elm版の開発等も進んでおり、後述するpoetryでもPubGrubが利用されている

PubGrubの提案者による解説記事。Dart側のドキュメントと照らし合わせながら読むと、Unit Propagation、Conflict Resolution、Decision Makingの対応が頭に入りやすく分かりやすい。
medium.com

 
本題のpip 2020-resolverでは、シンプルなbacktrackingが採用されている。このロジックは以下で議論されている。
github.com

ここでは、PubGrubベースのMixology*12やbacktrackingベースのResolveLibZazo、他にも先述したlibsolvMicrosoft Researchが提案したZ3などを比較し検討している。途中でpoetryのメンテナである@sdispaterがpoetryのリゾルバ部分を書き出したrepoを提示していたり依存解決リゾルバのアドバイスを行っている所も面白い。議論の結果、APIインターフェースやコミュニティ、開発速度の観点から、PyPAメンバーである@uranusjrが作成していたbacktrackingベースのresolvelibが使われる事になった事がわかる。解説は以下のブログ。
pradyunsg.me

ここでの選定理由は、特にピュアPythonで書かれている事がコミュニティないし支援企業がついている中で開発速度にとって嬉しい事が大きい要素になっている。
pip 2020-resolverのプロジェクトにはCZI社*13Mozilla*14による金銭的のサポートが入っており、PyPAにとっても重要なテーマであると言えるわけで、開発速度が得られるに越したことはない背景があった。
pyfound.blogspot.com
PyPAのメンバーであるソフトウェアエンジニアが、仕事の傍らボランティアで行ってきたpipの開発について、この2020-resolverの開発終了まで金銭面でのサポートする内容になっている。

 
この2020-resolverで、pipは強い依存解決を行うようになり、長らくpipで言われていた

“Why does pip download multiple versions of the same package over and over again during an install?”.
(なぜpipは同じパッケージの複数のバージョンを何回もダウンロードするのか?)

という大きな課題が解消し、速度も向上する事になる。この背景について、PyPAのユーザガイドにも長文で綴られているので、見ておくと良い*15
pip.pypa.io

 
 
少し横道に逸れるが、2020-resolverへの変更によってpip installで依存解決が失敗したらResolution Impossible エラーを出すようになる。これにより、多くのCI/CDが止まってしまったり、OSSに「あなたのパッケージpipでインストールできないんだけど」というissueが増えるのではといった懸念が思い付く。これらは、2020-resolverの展開方法として以下のissue等で議論されている。
github.com
大きな問題があればissueを追うか、ユーザガイドが示す通り、『How do I ask a good question?』を読んだ上で以下のコミュニティの何れかで質疑すると良い。

 

2020-resolverは2020年10月からデフォルトになっており、21.0には完全に古いリゾルバを使えなくなる*16今までpipenv等が依存解決を行っていた所にパッケージインストーラーだったpipが依存解決を行うようになるわけなので、全体に影響する大きな変化の1つであると言える。

 

pipenv

pipenvは、pipに対して、依存解決およびlockファイル生成、env環境制御機能の提供を行う、PyPAが開発するパッケージ管理ツールである。依存解決およびlockファイル生成にはpip-tools、env管理はvirtualenvを利用しており、それらを1つのPipfileと呼ばれる独自フォーマットで管理できるツールとなっている。
github.com

Pipfileは以下のようなフォーマットになっている。

[dev-packages]
coverage = "*"
yapf = "*"
mypy = "==0.580"

[packages]
numpy = "<=1.0.0"
pandas = "==1.1.5"

[requires]
python_version = "3.9"

ここでは、開発用のパッケージ、モジュールが利用するパッケージ、envの設定を記述する事ができる。

pipとの大きな違いは、先に挙げた依存解決、lockファイル生成、env環境の制御である。

依存解決アルゴリズムでは、pip-tools内で先程の2020-resolverと同様のbacktrackingを利用している*17
github.com
pipenvは、pip-toolsが持つlockファイル生成の機能をwrapしている状態であると言える。

env環境については、同じくPyPAが開発するvirtualenvの機能をwrapし、env環境を提供する形となっている。
github.com
先に示した通り、pipが依存解決を行わない動作をしていた頃に、依存解決の機能に加え、一般的なソフトウェア開発に必要なenv環境の提供を可能にしたツールである。

 
pipenvはpip同様、パッケージングについては完全に別で処理する思想を持っている。setup.pyやsetup.cfgを記述し、それぞれ別のツール(wheeltwin)を利用してbuild, publishを行いPyPIに公開するライフサイクルとなっている。publishに関連したそれぞれのツールもまたPyPAが開発しており、PyPAが示すPythonパッケージングのライフサイクルの主たる形であると言える*18

 

poetry

poetryは、pipenvに対して先のpyproject.tomlの仕様を拡張を利用し、依存解決からlockファイル生成、env環境管理、パッケージングまでを行えるようにしたパッケージ管理ツールである。先のPipenvと違い、PyPAではなく、1ユーザである@sdispaterが主導し開発されている。
github.com

READMEには『Why?』という章がありそこでは、pipenvに対する課題とpoetryを作成した経緯が書かれている。要約すると以下の3点になる。

  • setup.pyやrequirements.txt、Pipfileを導入せずcargoやcomposerのようにbuildしpublishしたい
  • pipenvの意思決定のいくつかが好みでなかった
  • より良い依存解決リゾルバの導入

 
まず、1つ目の課題を解決したのが、先にも紹介したpyproject.tomlである。pyproject.tomlには以下のようなセクションを記載する事で、パッケージングに関する情報を付与でき、poetryがこの情報を読む事でbuild、publishが出来るようになっている。

[tool.poetry.dependencies]
python = "^3.6.2"
pandas = "*"

[tool.poetry.dev-dependencies]
coverage = "*"
yapf = "*"
mypy = "==0.580"

[tool.poetry]
name = "sample"
description = "This is sample"
authors = ["author"]
version = "1.0.0"
readme = "README.md"
homepage = "https://github.com/author/sample"
repository =  "https://github.com/author/sample"
documentation = ""
keywords = ["Example"]

[build-system]
requires = ["poetry"]
build-backend = "poetry.masonry.api"

[tool.poetry]となっている箇所は、poetry独自の拡張セクションである。pyproject.tomlとしてフォーマットが決まっている事で、拡張セクションを追加出来るようになっており、そちらを上手く利用した形になる。

  
依存解決については、先述の通り、backtrackingを採用せず、PubGrubを最初から採用している。これによって、依存解決を高速に行えるだけでなく、backtrackingが依存ツリーを戻る量で制限しているような枝を探索する事ができるようになっている。具体的には、READMEに書いてある以下のような例でpipenvが失敗する依存解決を遂行できるようになっている。

pipenv install oslo.utils==1.4.0

実際はpipenvが利用するpip-toolsのリゾルバとの比較になるが、このリゾルバの違いによる問題については、pipenvとpoetryの違いに関する章で後述する。

 

Anacondaなど他ツール

少し記事タイトルと逸れるが、現状を知る意味で概論として他のツールにも触れておく。

 
ここまで書いてきたように、Pythonのパッケージ管理エコシステムは、常々PyPAという団体によって整備され、PEPを通して制定され、PyPAが、インストーラとなるpipを代表にパッケージングであるsetuptoolsやwheel、PyPIへのアップロードはtwine、仮想環境はvirtualenv、依存固定はpipenvとそれぞれ作ってきた経緯がある。

そんな中で、PyPA以外の全く別のツールや似通ったシステムが栄枯盛衰を繰り返しているのは、常々人が作るソフトウェアの難しさに触れる事に近しい。最初から誰もが満足するツールなど作れないし、Python自体のユーザが増えた事によるOSS界隈の情勢の変化、影響範囲の拡大、速度、文化など様々な要素がひしめき合った結果、poetryやその他多くのツールが生まれたと言える。


中でもAnacondaは、pipがまだ多くのライブラリのインストールに失敗しバージョンやenvを管理する方法が定まって無かった中で、挑戦的な方法を取ることで出てきたパッケージング管理ツールである。

Anacondaは、Anaconda,Incという企業が開発、運用している点やその他GUIやenv提供の機能を持つ特徴こそあるが、パッケージ管理の側面でも他ツールとは少し違う独特なツールである。
www.anaconda.com

Anacondaは、Anacondaリポジトリ*19なるpypiのミラーサーバから、「環境に応じた最も良いもの」をインストールする機能を持ったパッケージ管理ツールである*20。最も象徴的な例として、Pythonに近い界隈では「numpyが利用するBLASの違い」についての話題が毎年2,3度バズっている。Anacondaがインストールしたnumpyが早いというものだ。Google検索「numpy anaconda 早い」と検索し上から記事を見ていけば概ね把握できるだろう。
www.google.co.jp
他にもCUDAとDeep Learning関連ライブラリのバージョンを照合する機能など、手元の環境とライブラリの依存関係を照合する知識がなくとも構築出来るのが1つの"売り"であると言える。

反面、過去何度も多くの開発者やツールが「環境に応じた最も良い物を提供する」事に挑戦した結果と同様に、依存関係の差異に苦しんだり環境を破壊する結果になることもある。特にpipと併用する事がHardlinkによって困難な点が最も大きい*21。技術的なメリット・デメリットについては以下の記事には目を通しておくと良い。
www.anaconda.com

大きな企業単位であれば十二分な基盤やVMを上手く組み合わせAnacondaを利用した理想の環境で開発できる企業もあるだろうが、その破壊的な機能や近年企業規模に応じて有償化するようになり、導入におけるデメリットも存在するし、もちろん逆に良いこともある。

Anacondaは、過去pipのインストールがまだ不安定だった時期に登場し、依存解決や独自のpackage registryの提供で大きく貢献した。また依存解決リゾルバの改修にも積極的かつ、ミニマムなAnacondaにあたるminicondaも存在しており、大きな一つの勢力であると言える。

 
他ツールでは、先程から出てきているpip-toolsを利用する方法、rustで書かれたpyptoject.tomlで管理可能なpyflow等が現状の選択肢に入る。海外ではflitも人気があるようだ。


 
pip-toolsは、pipenvやpoetryと違い、env管理は別のツールで実施するという思想で作られているツールに当たる。その概念は、公式の以下の図が明確に表している。

f:id:vaaaaaanquish:20210320225037p:plain:w350
pip-tools公式repoより

ユーザはrequirements.inというrequirements.txtと同様のformatで、自身が利用したいモジュールのバージョンを記載する。pip-toolsが提供するpip-compileコマンドは、inファイルから依存する全てのモジュールのバージョンが固定された状態で記載されたrequirements.txtを生成するジェネレータの役割を果たす。また、hashを利用した固定にも対応している。ここで生成されたrequirements.txtファイルを利用してpip-syncコマンドでenv環境に流すという構想である。この思想に則りさえすれば、env環境と切り離せるため、複数人での開発等を考えた時、個々に手慣れたenv系のツールを使ってもらえば済むというメリットがある。

 

pyflowは、rustで書かれたPythonパッケージ管理ツールである。
github.com
機能としてもpoetryが採用するPEP 518、pyproject.tomlによる管理方法に加え、PEP 582にあたるカレントディレクトリに__pypackages__というディレクトリを作り仮想環境のように扱う方針に対応している*22。PEP 582はpythonlocflitpdmといったパッケージ管理ツールで採用されている新しい方針である。これによってユーザは、ほぼenvについて意識する事無く複数のPythonや開発環境を切り替える事ができるようになる。このようなPEP 582の採用も目新しいpyflowであるが、私自身はパッケージ管理ツールがPythonで書かれている理由はほぼないと考えており、依存解決やインストーラ含めて、より高速な言語で書かれて欲しいという気持ちもあり一目置いている。新興のツールという事もあり、現状では未対応のissueを見てpoetryと比較し利用していないが、挑戦的な選択肢として強く推せるツールとなる。

 
また他にも、pyproject.tomlを利用せずsetup.pyを含めて良い管理を目指すhatchや、オープンソースのソフトウェア構築ツールであるSConsに則り作成されているensconsRedHatが作成したpipenvとpoetryのいいとこ取りをしたminipipenv等も存在し、小さく機能を収める方向にいくか、理想の依存解決、複合ツールとして大きくなっていくか、どの仕様を採用するのか、違いが見え隠れする状態である。何度も言うが、これらの選択は、その場その場の要件次第でもあると思うので、利用用途の多くなったPythonという言語にとって、これらのツールが多く出てくる事自体は喜ばしい事である*23

 

まとめ

ここで一度話をまとめる。冒頭で示した主張には以下のような詳細に分かれる。

  • pipenvはPyPAが開発しているツールで同じくPyPAが開発するpipの機能を補っている
    • pipenvは依存解決器の機能を持つが、pipにもその機能が搭載されつつある
    • pipenvはvertualenvやwheel、twine含めてPyPAが作るエコシステムの一部である
    • pipenvはresolverとしてpip-tools内のbacktrackingを利用している
  • pipenvとpoetryの大きな"機能"の違いはパッケージのbuild・publishをサポートしているかどうか
    • poetryは基本的な機能はpipenvと同じ
    • poetry独自の機能はpyprojcet.tomlの拡張セクションによるもの
    • pyproject.tomlには各種設定を詰め込む事ができる
    • poetryはresolverとしてはpipenvと違いPubGrubを利用している
  • pipenv、poetry以外に他にも多くのパッケージ管理ツールが存在する
    • pip-tools、Anaconda 、flit辺りが人気
    • envやパッケージングなどの機能をどこまでをサポートするかの違い
    • package registryの違い、pyprojcet.toml(PEP 518)やPEP 582の採用の違い、リゾルバの違い


ここで、パッケージング管理を取り巻く重要なPEPを以下にまとめておく。

  • PEP 453 : pipをPythonが公式サポート
  • PEP 518PEP 517 : pyproject.tomlおよびbuildシステムの制定
  • PEP 582 : __pypackages__を利用した仮想開発環境の提案


PyPAが作っているか否か、小さく機能を収める方向にいくか、理想の依存解決、複合ツールとして大きくなっていくか、どの仕様、PEP、どのリゾルバを採用するのに各ツールの違いがある。

  

- pipenvとpoetryの技術的・歴史的背景 -

本章では、ネット上に多くあるpipenvとpoetryに関する議論で出てきがちな疑問、不満を以下の通りに分類し、それらに対してそれぞれ背景を追う形で紐解く。

  • パッケージングについて
  • pipenvはlock生成までの速度
  • pipenvは開発がここ2年滞っていた件
  • pipenvのissue対応
  • PyPAの開発フロー
  • 活動や対応に関するゴシップ

上記を追う中で、poetryがどのような技術を採用し、pipenvが何故そうしないのか、逆にpipenvのどこが良いのかを詳しく見る。

パッケージングについて

poetryはpipenvと違い、pyproject.tomlを利用する事で、指定のbuild systemないし、独自のセクションを利用して、pyproject.tomlのみでパッケージング出来るという話がある。pipenvとpoetryの機能の違いで最もよく挙げられる点である。

 

自系列を追うと、PEP 517が2017年9月、pipenv 1stリリースは2017年1月であり、前後関係としてPyPAがPipfileについて検討している間はpyproject.tomlのPEPのacceptに至っていない事がわかる。

また、pyproject.tomlを使えば全てのパターンのbuildが行えるかと言われると、元々setup.pyを書いていた事を考えれば当然そんな事はない。setup.pyでC言語で書いたサブモジュールをbuildしたり、外部のライブラリとリンクする実装などが代表的である。PyPAとしては、そういった問題の解決のためにwheelsetuptoolsも作っている訳なので、役割を考えればsetup.pyやrequirements.txtが担っていた役割とpipenvが持つ依存解決、バージョン固定、env管理という問題は別であるという認識になるのは自然である。

実際、poetryはそういったユースケースに対してbuildを提供する方法として、build = "build.py"のような機能を一応持っている。ただ以下issueの通り、ドキュメントには未だ記載はなく機能として安定、サポートされている状態ではない。
github.com
build scriptを柔軟に書けるというのは、wrapperとしての立ち位置を取る事が多いPythonという言語において非常に重要であるし、tomlだけで管理できるものはないだろう。またbuild scriptの実行もPyPAが長年かけてPEPで制定、整備、開発してきた部分であるので、それらへの対応を新しい開発者やツールが対応するのは相当な熱量がないと難しい部分も多い。

pyproject.tomlに集約されたり、パッケージングまで行える事で差別化が図られる一方で、こういった多くのbuildにどこまで対応するかがツールによって変わってくるというだけの話になる*24

 

lock生成までの速度

「pipenv lockが遅い」「poetry lockが早い」というのは、よく挙げられる話題の1つである。

lockファイル生成速度に関してpipenvのissueが乱立していたり、Slack、DiscodeSNS各所で議論されている。
#356#1785#1886#1896#1914#2284#2873#3827#4260#4430#4457、…


まず、先にpipenvとpoetryの依存解決リゾルバのアルゴリズムの違いがある事を挙げた。そうすると「pipenvもpoetryの実装を真似すれば?」「pipenvもpoetryのようにPubGrubをベースとした依存解決を行えば良いのではないか?」という意見を思い付くのは自然だろう。

一般的に依存解決を行いhash値によって利用モジュールのバージョンを固定する方法として、package registryがパッケージに対して返すhashを利用する方法がある。Node.jsのnpmやrubyrubygemsも同様の方法を取っている。Pythonにおけるpackage registryはPyPIになるが、PyPIAPIjson-apiへ移行したこと、またその内容にセキュリティ上の懸念がある事が、pipenvとpoetryの依存解決方法のアルゴリズム、そして実装の違いに影響している。
 

まず前提として、PyPIは2017年12月にそれまでのHTMLを利用したAPIエンドポイントをLegacy APIとし、json-apiの提供を開始した。これは、他のpackage registry同様の内容で、特定パッケージのhash値を含めて返してくれるというものである。
warehouse.pypa.io
json-api提供開始時期の問題もあって、poetryははじめからこのjson-apiが返す結果の多くを信頼し、依存解決を行っている。一方pipenvはこのAPIの結果を使わず自前でhash値を計算している。ここがpipenvとpoetryの根本的なlockファイル生成速度の差に繋がっていると言える。


さて、このjson-apiはpipenv開発開始以降に提供開始されたものではあるものの、pipenvに対しても「このjson-apiの結果を信頼し依存解決を行い、バージョンをlockするように変更すれば良い」という意見に繋がる。これにもいくつかの問題がある。

json-apiの1つ目の問題として、このjson-apiがPEPによって標準化されていないという点がある。先程のjson-apiのドキュメントからLegacy APIのページに行くと以下のような文言がある

The Simple API implements the HTML-based package index API as specified in PEP 503.

Legacy APIについてはPEP 503、その内容については、メタデータのバージョン2.0にあたるPEP 426に書かれており、メタデータjson互換オブジェクトを定義した2.1にあたるPEP 566もあるが、json-apiについて記載されたPEPは現状存在しない。PyPAとしてpipenvにこのAPIの結果を利用できない1つ目の理由になる。一方この問題は既にdiscuss.python.orgで起案されているので、こちらをウォッチすると良いだろう。
discuss.python.org


json-apiの2つ目の問題として、PyPI(正確にはhttps://pypi.org/)のartifact hashの一部が一度インストールしてみないと分からないという点がある。PyPIは、一度アップロードしたバージョンを同じバージョンで上書きする事はもちろんできない。一方、build済みのパッケージをtar.gzにdumpしたwheel形式以外に、buildスクリプト含めたsdist形式をアップロードできる。後者は、そこに正しくメタデータが設定されていない限り、特定バージョンのartifact hash自体は一度インストールしてsetup.pyを動かすまで未知になる。この未知のhashが厄介者になる。

PyPIは、一時的なhashを返してはくれるので、全幅の信頼を置いて依存解決の情報として使う事もできるし、全く信頼せず依存解決に必要な各バージョンのbuildスクリプトをダウンロードして手元でbuildしてhash値を計算するという事もできる。poetryは一部をjson-apiとし一部を手元でbuildする方針を取っており、pipenvは先述のPEP問題を含めて後者のように完全に手元で全てのパッケージをbuildする方針になっていた。これだけでも、pipenvが遅い理由が容易に想像付くはずだ。

 

この違いはあるものの、pipenvは、buildしたパッケージを出来る限りキャッシュして高速化する改修を過去何度も行っているだけでなく、2020年5月のReleaseではJSON-APIではなくURLフラグメントからhashを計算する形で依存解決の高速化を行っている。
github.com
これでかなり早くなった事が実感できるはずである。他にも #2618#1816#1785 #2075辺りの議論を追うと良い。

そしてもちろん、poetryも一部のパッケージを手元でbuildしている訳なので、そのパッケージを挙げて「lockが遅い」と指摘するissueが存在するし、poetryのドキュメントにも記載がある。
github.com
python-poetry.org
要は、実装の問題というより、思想としてartifact hashをどう考えるか、どう処理するのかの違いにlockファイル生成の速度の差があると言える。

そして先に出てきた、依存解決リゾルバのアルゴリズムの違いも、この問題に起因している。手元で多くのパッケージをbuildする方針の場合、PubGrubが、依存解決を行いながら、その場に応じてパッケージをbuildする機能を持つ必要がある。PubGrubは、そのアルゴリズムの特性上、途中でbuild処理をしながらその結果を比較するロジックを実装する事に向いていない。これについては、先程のpipの2020-resolverの議論でもpoetryの作者が指摘しており、poetryの作者がMixologyとして依存解決リゾルバのロジックをpoetryから切り出したにも関わらず、2020-resolverのロジックとして採用されなかったという背景にもつながっている。ここで、適切にbuildしながら依存解決を行うPythonによるPubGrub実装があれば話が進む可能性はもちろんあり、pipgrip等のOSS実装が出始めてはいるといった状況である。

 
さて、この非決定的なartifact hashについては、PyPIメンテナが書いた以下のブログに理由を含めて記載されている。
dustingram.com
より過去のhash自体の議論については以下を追うと良い。

 
この問題が完全に解消されるには、「下位互換を完全に切ったPyPIのミラーが作られる」だとか「setup.pyを捨て全てがpyproject.tomlになる良い方法が提案される」だとか「PyPIサーバ内でbuildが走る」だとか複数の道があるわけだが、歴史の長いPythonパッケージングの問題やbuildスクリプトが走る事でのセキュリティの懸念、サーバの金銭面などを全て解決されるには時間がかかるのは当然と言える。

 

pipenvは開発がここ2年滞っていた件

pipenvには「開発が滞っている」「2年更新のない死んだプロジェクト」などの指摘が多くある。実際、2018年11月(v2018.11.26)から2020年5月までReleaseがなかった。2020年5月のReleaseも、当初予定していた2020年3月から4月21日に延期され、4月29日に延期、その後5月にReleaseされたという背景があり、この辺りを挙げ開発が滞っているとする指摘も多い。

これらは、2020年のRelease Noteやtracking issueを見るのが良い。
discuss.python.org
tracking issue: https://github.com/pypa/pipenv/issues/3369

ここまで示した通り、pipenvはPyPAが開発する多くの他プロジェクト、pipやvirtualenv、setuptoolsに強く依存しているし、その意思決定の多くがPEPという大きなプロセスを通して行われている。空白の2年間の如くpipenvが止まっていたように見えるだけで、関連度が高く、依存した多くのプロジェクトの改修を行っていた訳で、開発が滞っているという指摘自体が間違っていると言える。

なによりPyPAはNumFOCUSといった支援団体があるとはいえ全員ボランティアであるし、Release Noteを書いているDan Ryanは仕事をしながら20%ルールの範囲で開発を行っていると書いてあるしで、外から多くを求めるだけというのは間違いだろう。またこのRelease Noteには「Other changes in the project」という章がある。それはProcess changes、Communications changes、Release cadence & financial supportの3つに分かれており、PyPIへの貢献のプロセス、コミュニケーションを変える事を約束し、別の形で「パッケージングエコシステムに対して」貢献できる形を提供すると発表している。

議論やcommitmentに至る程の背景知識がないが、このパッケージング問題に金銭面で貢献したいといった場合は、以下を読みdonate.pypi.orgに行くと良いだろう。
pyfound.blogspot.com

 

pipenvのissue対応

poetryが個人開発から始まっているのに対して、pipenvがPyPA主導である事から、issueへの対応の違いが指摘される事がある。「pipenvはissue対応が遅い」といった意見だ。これは、PyPAが元々issueを多く使っていない事に起因しているが、pipenvでたまに返信があるissueもあったり、ツールも分散しているので一見ではissue利用の思想について把握しづらいとも言える。

さて、先にpipの2020-resolverの問題の相談先として以下を挙げた。

これに加えてパッケージングに関しては、以下のような場所の議論を追う必要がある。


他PyPA関連のプロジェクトの多くの議論場所は以下のページにまとめられており、Slackからメーリングリスト、freenodeをチェックする事が求められる。
packaging.python.org

一見混乱するかもしれないが、開発者からしてみれば、接触確認アプリCOCOAがissueを利用していないにも関わらず未対応であった事を指摘していた人と何ら変わらないので、正しく議論したい場合は念入りに読み込んで、適切な場所に意見を投稿すべき、という話になる。

 

PyPAの開発フロー

PyPAの開発フローしんどい問題も少しだけある。もちろん影響範囲が大きいし、PEPや歴史的背景を持つ大きなプロダクトなので当然ではある。

例えば、実際「pipenvに一度貢献したがもうやりたくない」といった意見もある。
github.com
フローと歴史的背景を多く要求されるだけでなく、交渉の末MRを出すもcloseになる事がある。実際に私も過去python devのSlackでパッケージング管理問題に触れた時、多くの回答とフローを用意され尻込みしてしまった経験を持っている。

 
また、PyPAのツールにおいて少し特殊なのは、Vendoringという開発手法を用いている事が挙げられる。
これはRustやGo等ではgit submoduleのような形でよく使われる手法で、利用するモジュールを依存関係として取るのではなく、同一のRepository内に含めてpatchを当てて開発していく手法である。日本語であれば以下が詳しい。
qiita.com

pipenvのrepogitoryの以下ディレクトリを見ると、vendoringされたツールが多くあるのが分かる。
https://github.com/pypa/pipenv/tree/master/pipenv/vendor
これは、LICENSEやネストといった既知の問題こそあるものの、PyPAが作るツールのような「ある依存モジュールが突然PyPIから消えて動かなくなったら困る」といった再現性が必要な場面で有用な手法である。

一方で、ことPythonにおいてはvendoringに関連した文化やツールがそもそもないので、pipenvにその問題を指摘するissueが立ったり、vendor先のツールに「このrepoメンテする意味ある?」といったissueが立ったりしている。
github.com
github.com
当然upstreamとして機能し取り込まれる可能性があるので意味はあるのだが、Pythonという言語内でのvendoringの文化として浸透していない証拠とも言える。


ただ、開発フローに関しては、個々時々に応じて対処していけば良い問題であって本質的ではない。貢献する気概を持って貢献するだけだろう。そして何より、先述の2020年5月のRelease Noteを使って体制を改善するとまで言っていることからも、PyPAが真摯にこの課題に向き合っているのが分かるので、期待する所でもある。

 

活動や対応に関するゴシップ

issue対応や開発フローも技術的な背景から遠いが、pipenvやpoetryの議論の歴史も存在しており、それらを知る事で適切にコミュニティとコミュニケーションが取れると思うので、短くまとめておく。

昔々、当然PyPAメンバーはpipenvを推していて、メインメンテナであったKenneth ReitzがPyCon2018で発表するなどしていた。一時期pipenvのドキュメントのトップには以下のような文言が存在した。

the officially recommended Python packaging tool from Python.org, free (as in freedom)

冒頭のtheを含めて直訳すると「Python.orgが公式に推奨する唯一のPython パッケージングツール」というニュアンスになる。「PyPAは公式に推奨されているのか」「唯一のツールなのか」等、文言やその他の活動に対して揚げ足を取るような形で、機能や対応に不満を持っていたユーザの意見が噴出した。十分でない機能をREADMEで揶揄するプロジェクトが出たり、ブログやSNSでも話題になっていた

以下のようなタイトルのissueもあり、コメントやリアクションを見るになかなか殺伐としているのが伺える。
If this project is dead, just tell us · Issue #4058 · pypa/pipenv · GitHub

そんな最中、作者のKenneth Reitzが「Python.orgが公式に推奨する唯一のPython パッケージングツール」の文言をmaster commitで削除したりした*25事や、攻撃的な意見が辛く精神的に病を抱えている事を告白する記事を公開した。

そしてredditやissueで、全ての不満と共にKenneth Reitzのパフォーマンス説を唱える人が出たり、そういった人達と本当に技術について議論したい人が入り混じり炎上、PyPAメンバーやPythonメンテナが対応する事になった。

これらについてはPyPA、Pythonそれぞれから回答があり、以下を参照すると良い。
github.com
github.com


誤解を招かないため、更に書くと、pipenvやpoetryの不仲などと言った事もなく、上記redditスレ内でもpoetry作者とも話した上で設計思想の違いを認識している事が書かれているし、pipの2020-resolverを決定する際には両メンテナ、Pythonメンテナがそれぞれのリゾルバについてや依存解決のコツを投稿しているので、決して悪い方向に進んでいるような話ではない。
実際、現在のPythonのパッケージングに関するチュートリアルには、pipenvやAnaconda 、poetryを適切に選定する事が良いとされている。
packaging.python.org
技術的には本質ではないものの、知っておく事で、コミュニティがこういった攻撃的な投稿に関する話題に敏感である事を鑑みながら、丁寧に投稿できるようになればと思う程度の話である。

 

まとめ

本章のpipenvとpoetryの違いについて、以下にまとめる。

  • build/publishの機能の違いはpyproject.toml誕生の前後関係とPyPAのエコシステムの思想からくるもの
  • lockファイル生成速度は、PyPIjson-apiの結果をどこまで信頼し、どこまでパッケージを自分でbuildするかに関係
    • 依存解決リゾルバの違いもここに縛られている側面がある
    • 解決するにはいくつかの方法こそあるが、下位互換やセキュリティ、金銭的な側面の課題もある
  • Pipenvはissueではなくメーリングリストを利用して開発が進んでいる
    • 徐々にissueでの議論も進んでおり開発フローの改善も進む
    • poetryの方が開発体制が良いという訳では必ずしもない
  • それぞれゴシップ的な炎上を経験しておりディスカッションに参加する場合は丁寧な理解をしておくと良い

念の為フェアに補足しておくと、pipenvには、PyPIにアップロードされたパッケージが変更されていないか等の脆弱性を確認するPEP 508に則ったpipenv checkの機能もある*26。ある意味特徴的な機能の1つだ。
pipenv.pypa.io
これらを加味しながら、適切にツールを選ぶ事が良いと考えられる。

 

- poetry大臣としての活動記録 -

ここまで、Pythonのパッケージング管理ツールについて取り扱ってきた。そして、私が所属する企業、チームでも、実際にpipenvによるパッケージ管理とデプロイ、CI/CDが使われていた。しかし、運用する中で前述のようなパッケージング管理ツールの違いを踏まえて、社内の課題と見比べ、poetryへの移行を行う形となった。本章は、その移行作業の目的や判断基準、感想を綴るものである。

重要な分岐点になった、以下の3つのセクションについて書いていく。

  • VPN必須なpipenv lockがかなり遅かった
  • 乱立するファイルと管理場所
  • gokartなどOSSとの管理方法統一

 

VPN必須なpipenv lockがかなり遅かった

私が所属企業では、社内のPyPIを通してpipによるインストールを行っている。社内PyPIへの接続にはVPNが必須であった。

ちょうどコロナで全社でのリモート化が進み、在宅勤務が増えた事でVPNの負荷が増大、それに伴ってpipenv lockに膨大な時間がかかるようになっていた。基本的に1時間以上は基本、大きなrepoでは2,3時間を要して、途中で接続がタイムアウトしてしまうような事もあった。実際、深夜の障害対応中に「hot fixでバージョン戻してReleaseしましょう」「では、lockします」「・・・(終わりは3時だな)」といった会話が発生するなど、本当にあった怖い話もいくつか体験しており、流石にlockファイル生成速度の問題を看過できなくなっていた。


先述した通り、pipenvの設計思想の課題であって根本的な解決が難しいことも考慮し、別ツールへの移行を考える必要があった。検討したのは、pip-tools、poetry、flitであった。中でもpip-toolsは強く検討したが、各々がenvを設定するコストやpyproject.tomlが今後主流になるだろうという憶測から、poetryとflitに絞って検証を行った。

移行当初、flitが抱えていた課題として、パッケージのバージョニング機能が不十分であるという課題が存在した。具体的には、gitタグやVERSION.txtを通してパッケージのバージョンを決める方法の有無で、これによってCIによるバージョンやpublishを行う所作が、所属チーム内では広く行われていた。

poetryには、poetry-dynamc-versioningという拡張が存在し、こちらを利用する事で、上記問題が解決できる事が分かったため、以降先としてpoetryを利用していく運びとなった。
github.com

 

乱立するファイルと管理場所

所属チームでは、基本1人1プロジェクトで開発を進めており、そのプロジェクト数は大小や稼働率、廃止撤退様々あれど36個にも登る*27

私が入社当初、プロジェクトテンプレート等はなく、各々自らが知るツールを使ってRepositoryを作っていた。その後、私がcookiecutterによるプロジェクトテンプレートを作ったものの、そういうった背景を鑑みないrepoは増え、プロジェクト管理は以下のようなファイルに分散していた。

  • requirements.txt
  • setup.cfg
  • setup.py
  • VERSION.txt
  • Pipfile
  • Pipfile.lock
  • pip.conf
  • code_analysis.conf
  • yapf.ini
  • MANIFEST.in

中にはバージョン情報がrequirements.txtとPipfileに分かれて書かれており、初見ではどこで指定されているモジュールがproductionで使われているのか分からないようなプロジェクトも存在した。poetryとpoetry-dynamc-versioning、toxというテストを統一的に管理するツールを導入する事で、以下の3つに全てのファイルを集約できる事が大きな後押しになった。

  • pyproject.toml
  • poetry.lock
  • tox.ini

github.com

これは、最近Preferred Networks社のブログでも語られたような内容なので、普遍的に多くの企業で課題になっているだろう。
tech.preferred.jp
(PFNはそういった課題に対してpysenのようなツールを公開するにまで至っているのだから流石である)

私の所属企業では、poetry、poetry-dynamc-versioning、toxを利用する事によって既存のメンバーだけでなく、新しいメンバーに対しても混乱を産まず、いくつかの設定の場所と使い方を覚えるだけで開発に専念できるようになり、多くの問題を解消することができた。企業によっては、インフラやCI、要件の関係で他ツールを選ぶこともあるだろうとは感じるが、横串でツールの要件が決まっている事での開発速度の差は何より大きい。

 

gokartなどOSSとの管理方法統一

私の所属企業として内部で使われるツールを外向けのOSSとして公開しているが、チームメンバー全員が使うにも関わらずメンテナが一部のメンバーに偏ってしまっていた課題があった。様々な理由こそあったが、日頃使っているツールとの差異が大きく、パッケージングやフォーマッタのツールに社内との微妙な違いがあり、またbuildやpublishをメンバー個人ができない状況で、新規に開発に参入しづらいという課題が大きく存在した。

そういった背景から、社内でpoetryを推進した後、外部のOSSをpoetryに移行する運びで解消する事にした。
github.com

 

活動全体の感想

先述のような前提を踏まえ、私が2020年4月にpoetry移行をスタート。

f:id:vaaaaaanquish:20210326164741p:plain
2020年4月に自己宣言

1年かけて、コツコツと様々なプロジェクトにPull requestを出し、先日稼働中のプロジェクト全てがpoetryに移行した形になった。

f:id:vaaaaaanquish:20210329002427p:plain
ROI勘定


Pipfileからpyproject.tomlの移行は、toml形式を互いに採用しているところからもほぼ困難なく移行する事ができた。

移行時は、pyproject.tomlがデファクトスタンダードにならなかった場合にpyproject.tomlに多くの設定が集約される事でロックインされてしまうのではという懸念を持っていたが、現状多くのフォーマッタやlinter、testツールがpyproject.tomlをサポートする流れになっており、良い選択だったと言える。

poetry-dynamic-versioningを利用した、pythonパッケージ用のrepoの設定の仕方の記事を書くなどした。
vaaaaaanquish.hatenablog.com

また、同僚の @SassaHero がyapfをpyproject.tomlの対応をするなどした。

チーム管理のOSSであるgokartには、poetryやtoxが導入、かなり少ないツールと設定ファイルで多くの処理が行えるようになった。結果社内外からのコミッターも増えて万歳という結果になった。

 

- おわりに -

本記事では、pip、pipenv、poetryという3つのパッケージ管理ツールについて、技術的、歴史的背景をまとめ、それらを元にpoetry移行を行った経験を綴った。

そもそもパッケージ管理が最初から全て上手くいっているプログラミング言語などない。フロントエンド系だって、様々な設定ファイルやメタプログラミングを通してpackage.jsonやtsconfig.jsonに行き着いているし、JVM系のようにhash照合の概念がなくpackage registryをSpringが立てているようなところもある。package registryを捨て、gitのコードベースに依存解決を行っている言語もあれば、RustのCargoを見れば、fmtからtest、doctest、build、パッケージ依存解決、パッケージングを行えるたった1つのツールを上手にメンテしている。

私個人の本音を言えば、Cargoくらい全ての事が詰まったツールは欲しい。


特にpyproject.tomlベースでPEP 582も扱いたいし、できればtestやlinterも1つのツールに収まっていて、スクリプトで管理するのはごく一部でロックインされず気軽に乗り換えられるのが嬉しいが、そんなモンスターのようなツールのメンテは想像するだけで骨が折れる。PyPIjson-apiがPEPを通るか、Anacondaのようにpackage registoryを構える偉大な団体が出てくるかといった依存解決についての解消も必要だろう。

一方で、これは作ってない人のお気持ちであって、pyproject.tomlとbuild script以外にPythonを書くツールも出てきており、pyproject.toml以外の選択肢がパッケージングという観点以外のlinterやapi config、その他設定を起因に出てきた時移行できるよう、ロックインを避けるようにしていくのがベターだろう。

PythonC/C++のwrapperとして多くの機能を持っている事も加味すれば、今後もbuild scriptは必須になるだろうし、元来、パッケージ管理ツールといった代物はプロダクトコードとは別のレイヤーに居るのだから、あとはプロジェクトのサイズ感や運用状況と相談し、ベストプラクティス等と言わず、そういったツールに固執せず、粛々と運用し、適切に時期をみてツールを変更していくだけという話である。

 
何より私はPyPAのコアメンバーでもなければ、パッケージ管理ツールの主要なコミッターでもないので、大きく発言する資格はないし、donate.pypi.orgNumFORCUSを支援するか、issueやcommitやコメントを重ねるか、自分で理想のパッケージを作るかをやっていかないといけない。それがソフトウェアエンジニアとしての常である。頑張りましょう。

 
かなり長くなってしまったので、整合性が取れていなかったり誤認に基づく間違いがあるかもしれない。
できれば、Twitterはてブに書いて頂ければ幸いです。
ちゃんと議論したい場合は、文中の通り適切な場所にどうぞ。


// -- 2021/03/29 追記 --

GitHubがpackage registoryに成り得るサービスを展開していて、Pythonもfuture workに入っている。ここにindexされ、常用が始まるのを機に後方互換が一気に変わって、依存解決が超簡単になって、管理もGitHubないしMSがやってくれるというコースもワンチャンあると思っている。その場合、ユーザが利用するツールがどう転ぶかは未知数だ。などとGitHub Packagesが出てから思い続けて、future workになって2年経つので、いつになるかはよくわからない。一応future workになった時点で2021年の3月以降とされているから、今後なにかある可能性は高い。

 

- 参考文献 -


脚注や文章内リンク外で参考にしたもの・本記事を理解する上で読むと良いもの

f:id:vaaaaaanquish:20210329011401p:plain:w0

*1:サードパーティPythonモジュールがアップロードされているリポジトリ

*2:統一的でない事に対する悪い意味合いではなく目的に応じてツールが分離されたエコシステムであるという意

*3:pip install -r pyproject.toml出来ないよねといった議論はあるがsetuptoolsと共に徐々に対応されていくだろう https://github.com/pypa/pip/issues/8049

*4:PyPAが出すチュートリアルにはsetup.pyやsetup.cfgも適切に使えとは書いてある https://packaging.python.org/tutorials/packaging-projects

*5:何かを入れた後にサブモジュールをインストールしなおすと治るといった現象にPythonユーザであれば当たった事があるはず

*6:充足可能性問題 - Wikipedia

*7:バックトラッキング - Wikipedia

*8:私は高専時代Knuth先生のThe Art of Computer Programmingで挫折したことがあり教科書的と言える知識量ではないかもしれない…

*9:Dart開発者向けのドキュメントはここ pub/solver.md at master · dart-lang/pub · GitHub

*10:のように私は見える

*11:Unit propagation - Wikipedia

*12:poetryが採用している

*13:Chan Zuckerberg Initiative - マーク・ザッカーバーグと妻のPriscillaChanが持つ投資会社

*14:言わずもがなfirefox作ってる会社

*15:Python2もサポート終了で早く止めろと言っているので各位には早く止めてもらいたい

*16:今はまだ--use-deprecated=legacy-resolverで古いリゾルバを利用できる

*17:自系列的にはpipenvの方が先に依存解決をはじめている

*18:主たる形であってPyPAは他の方法を否定はしていない

*19:Anaconda Cloudやその他のリポジトリが存在するがここでは総称する

*20:より具体的にはwheelを選んでくれる

*21:もちろんenv毎に容量が節約される等のメリットもある

*22:poetryでも議論されておりメンテナも好意的 PEP 582 support · Issue #3691 · python-poetry/poetry · GitHub

*23:乱立しているだろうという観点はさておき

*24:私も手前xonshのxontrib等はpoetry化できないし、逆にsetup.pyのメンテを引き剥がす作業も行っている

*25:「他に適切な表現があるため」としており間違った行為ではない

*26:依存解決とは別の意味でセキュリティ関連の解説が必要なため、どうしても誤解を招かず書くことが難しかったので後述する形となった

*27:A~Zで偉人の名前でプロジェクトを管理していたが、今は一周し花の名前で2週目になっている