Python パッケージングは​​今では素晴らしいです: 必要なのは「uv」だけです

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

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

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

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

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

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

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

UVを入力してください

2月15日にAstralが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 をインストールします」と答えることができます。

いくつかの反省

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

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 を使用しており、過去を振り返ることはありません。私は今後もこのツールを皆さんにお勧めし、話し続け、さらに普及することを願っています。

以上がPython パッケージングは​​今では素晴らしいです: 必要なのは「uv」だけですの詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。