この投稿のタイトルは、Glyph の Python Packaging is Good Now への参照です。この8年間で、私たちは「良い」から「素晴らしい」に変わったと言って間違いないと思います。私の推論を読み続けてください。

Python のパッケージ化が初心者にとって難しいのはなぜですか?

私は、Python パッケージ化の 2 つの主な困難は次のとおりであると主張します。

• ブートストラップ、つまり開始方法!
• アクティベーション、つまり Python の venvs がどのように機能するか (説明するのは非常に難しいので、私の Mastodon スレッドを参照してください!)

ブートストラップは無視されがちな問題でした。 https://python.org から Python をインストールするように人々に伝えるべきでしょうか?アナコンダのディストリビューション？システム パッケージ マネージャーを使用してすべてを壊す危険を冒す人々を阻止するにはどうすればよいでしょうか?

仮想環境のライフサイクル全体を忘れないでください。長年 Python ユーザーとして過ごしてきた私が、Python にどれだけ無感覚になっているかは本当におかしいのですが、それを説明しなければならないたびに、生徒の顔を見て「これはダメだ」と思います。

確かに、配布可能なパッケージをビルドして公開する方法など、他にも問題があります。しかし、これらはほとんどの Python 初心者 には影響しないと私は主張します。さらに、それらも同様に対処されつつあります。続きを読んでください。

UVを入力してください

2 月 15 日にアストラルが uv をリリースしたので、私はすぐに飛びつきました。仕事の一環として、競合する可能性のある依存関係を多数インストールする必要が日常的にありますが、uv のおかげですぐに安心できました。

しかし、興味深いのは、現在 uv が初期の「より高速な pip」フェーズをはるかに超えて、「高速で信頼性が高く、使いやすい包括的な Python プロジェクトおよびパッケージ マネージャー」という約束を果たしているということです。

最初に述べたブートストラップとアクティベーションの問題に戻りますが、UV はそれらをどのように解決するのでしょうか?これを考慮してください:

• uv は Python 自体には依存しません。プリコンパイルされたスタンドアロン バイナリは、Linux、macOS、Windows に簡単にインストールできます。
• uv python は Python のバージョンを管理します。 pyenv や Deadsnakes などの OS 固有のメカニズムや、conda などの強力なツールに頼る必要はありません。
• uv ツールは集中環境でツールを管理します。 pipx やフェードはもう必要ありません。
• uv init は、ビルド バックエンドとしてハッチリングを使用し、空の README とダミー モジュールを含む動作する src-layout を使用して、ベアボーン pyproject.toml を作成します。
  • より洗練されたものが必要な場合は、コピー機またはクッキーカッターを使用して、より洗練されたテンプレートを使用できます。
• uv add は pyproject.toml に依存関係を追加し、venv が存在しない場合は作成し、それらをインストールします!
• uv lock は、すべての依存関係を含むロック ファイルを作成し、uv 同期で使用できます。
  • そして、古き良きrequirements.txtが必要な場合は、pip-toolsと同様に、uv pip COMPILEがそれを実行します。
• uv run は、やはり 環境を明示的にアクティブ化せずに、スクリプトとコマンドを実行します!

基本的には次のとおりです:

$ mkdir uv-playground
$ cd uv-playground
$ uv init
warning: `uv init` is experimental and may change without warning
Initialized project `uv-playground`
$ uv add click
warning: `uv add` is experimental and may change without warning
Using Python 3.12.3 interpreter at: /usr/bin/python3
Creating virtualenv at: .venv
Resolved 3 packages in 66ms
   Built uv-playground @ file:///tmp/uv-playground
Prepared 2 packages in 430ms
Installed 2 packages in 0.62ms
   click==8.1.7
   uv-playground==0.1.0 (from file:///tmp/uv-playground)
$ tree
.
├── pyproject.toml
├── README.md
├── src
│   └── uv_playground
│       ├── __init__.py
└── uv.lock

3 directories, 4 files
$ uv run python -c "from uv_playground import hello; print(hello())"
warning: `uv run` is experimental and may change without warning
Hello from uv-playground!

したがって、「コンピューターで Python の学習を始めるにはどうすればよいですか?」という質問には、誰でも「UV をインストールします」と答えることができます。

いくつかの反省

仮想環境の話題については、アルミンの意見に基本的に同意します

npm は「アクティベーション」に相当するものを何もせずに済んだので、将来の Python エコシステムも、virtualenv アクティベーションにはあまり役に立たなくなると思います。

また、uv init が孵化したばかりの子を選択していることにも気付きました。私は常に PDM を少し好みましたが、これはもう引き返せないポイントかもしれないと思います。

Leah と寄稿者は、PyOpenSci パッケージング ガイドのこの決定図を思いつくまでに多大な労力を費やしました。しかし、より具体的なニーズ (Meson や scikit-build 対応のビルド バックエンドなど) がある場合に変更できる ベースライン が存在するという事実は、開発者エクスペリエンスをさらに向上させます。

コンダについて

conda と pip の話題も、よくある混乱の原因です。私は初日から conda ユーザーでありファンでした。Windows に何かをインストールするだけで非常に困難だった当時、conda のおかげで Python は明らかな死から効果的に救われました。

その後数年間、私は Jake VanderPlas による違いを説明した古いブログ投稿を頻繁に参照しましたが、今ではそれは失われた大義のようです。

pip と conda の間の相互運用性の問題は完全には解決されていませんでした。Pixi の人々は素晴らしい仕事をしていると思いますが、長期的には uv が勝つと思います。

conda パッケージが非 Python コードの概念に基づいてより適切に構造化されていること、および「PyPI 上のファット ホイール」の現在の世界が明らかに次善のソリューションであることを私は完全に認めています。しかし、エコシステム全体がその方向に動いています。現在、ほとんどのパッケージは、さまざまなプラットフォーム向けにプリコンパイルされたホイールを公開しています。

言い換えれば、conda は 2024 年には 2014 年ほど役に立たなくなる可能性があり、初心者に conda を教えるのをやめて高度なツールとみなす時期が来たのかもしれません。

結論

少し時期尚早である理由は、これらの UV コマンドの一部はまだ実験段階であり、将来的に進化する可能性があるためです。しかし、標準に準拠し、包括的で、ブートストラップの問題がなく、慎重に設計され、勝利できるワークフロー ツールを初めて明らかにしました。

これは多くの Python パッケージング評論家がずっと望んでいたものですよね?多くの異なるツールから選択する必要はありません。しかし、uv はそれをはるかに超えて、他の開発者エクスペリエンスの問題も解決したと思います。私はそれを嬉しく思い、感謝しています。

私はあらゆることに効果的に UV を使用しており、過去を振り返ることはありません。私は今後もこのツールをみんなに勧め、話し続け、さらに普及することを願っています。