uvとその柔軟性は本当に素晴らしいよ。pipが10分かかるところを、uvは20〜30秒で処理できるからね。

でも、pyproject.tomlにPythonのバージョンを保存しているんじゃないの？それならPythonのバージョンファイルは必要なの？

+1、これがuvを使い始めた理由そのものだよ。めちゃくちゃ便利。ただ、なぜかuv pipがすごく遅いんだよね。理由はわからないけど、うちの組織が変なネットワークのことをやってるのかも。

Pythonの世界では、ロックファイルは「インストールプロセスの奇妙なステップ」として扱われることが多く、バージョン管理にはコミットされていないことが多いね。

でも、どんな対策が考えられるの？ロックファイルが全くないなら、それは初回の実行か、後でgitのアップストリームから上書きされることになるだろうし。壊れているなら、誰かがパッケージのインストールをミスった可能性が高いし、新しいロックファイルを作成するのが一番理にかなっていると思う。こういう稀なエッジケースを扱う感じもするけど、かなりシンプルな方法だと思うよ。

実は、これはuv syncが提供する--lockedオプションでカバーされています。uv sync --lockedを実行すると、ロックファイルが存在しないか、古い場合は成功しません。追記：あなたのコメントを少し誤解していました。ロックファイルがない場合や、指定した依存関係と一致しないロックファイルがある場合は、人間が介入すべきだと強く同意します。だから、ビルドの際には必ず--lockedオプションを使うことをお勧めします。

これはプロセスの大きなバグだね。これを言うためにコメントを見に来たよ。彼らはこう言ってるけど、君が指摘した通り、正反対のことをしてる: > 「--frozenフラグはロックファイルが更新されないことを保証します。」 それがまさに私たちが望んでいることだよ。ロックファイルには、インストールするすべての依存関係の正確なバージョンの完全なリストがあるべきだから。

みんながまだuvを使ってないから、こんなに混乱してるだけだと思う。

そう、めちゃくちゃだよ（新しく：Rustも追加！）

そうだね。言語設計の初期段階でこれを正しくやることが大事だよ。バージョン2.0まで先延ばしにしない方がいい。実行可能なスクリプトにパッケージやモジュールのメタデータを入れる前に、二度考えよう。それを決めたら、さらに三度考えてみて。言語によっては（Common Lispみたいに）うまくいくこともあるけど、他の言語（Pythonみたいに）ではそうじゃないこともあるからね。

依存関係で問題があったことはないよ。どうして混乱してるの？プロジェクトごとにrequirements.txtとvenvがあるんだから、これ以上簡単にはならないよ。

pipと全く同じようには動かないよ。大きな違いについてはここに書いてあるよ: https://docs.astral.sh/uv/pip/compatibility/ いくつかはuvが標準に従っているけど、pipはまだレガシーな動作から移行中だったり、デザイン上の選択でuvが決めたこともある。標準があいまいだから、特定のツールの選択だったり、uvが何らかの理由で標準に従わないことにしたりしてるんだ。

PythonのツールがPython以外の言語で書かれるのには完全に反対だ。 あなたがPylintの実行が終わるのを待っている間、私は日差しを楽しんでるよ。

Rust（またはPython/C以外の言語）をPythonツールに使うことに対するあなたの反対理由は何なの？具体的な理由を言ってないよね。

RustはPythonやCにはない機能セットを提供してる。もしRustがその仕事に適しているなら、そのコードはRustで書かれるべきだと思う。サポートは実装言語よりもインセンティブ構造に関係してる。

俺は、ツールがどの言語で書かれてるかなんて気にしないよ。確かに、これらのツールを使うユーザーがPython開発者なら、理論的には貢献できるって気持ちはわかるけど、ツールがちゃんと機能してれば「Pythonじゃないから」ってのはどうでもいい。むしろ、Python環境のセットアップに関する問題があって、そのツールがPythonで書かれてたら、逆に壊れちゃうかもしれないと思う。

理論的には君の言ってることには賛成だけど、実際にはPythonで書かれたパッケージマネージャーがuvほど良いものに出会ったことがないんだ。速度のことは言ってないけどね。uvはPythonで書かれてもいいと思うけど、実際にはそうじゃない。

Pythonは俺の好きな言語だけど、uvを完全に受け入れたよ。めちゃくちゃ簡単で速いから、他に近いものはないね。古いサーバーでEOLのディストリビューションを使ってて、壊れるのが怖くて誰も触れないような環境で最新のPythonが必要？uvだよ。小さなスクリプトのために依存関係が一つか二つ必要で、共有するためにパッケージ化するのが面倒？uvだね。とはいえ、拡張機能に関しては君の意見にちょっと同意する部分もある。数年前から進めてるサイドプロジェクトがあって、最初は純粋にPythonで作ったんだ。それを使ってPythonの遅い部分を学んで、どうやって回避するかを考えた。その後、もっと負荷のかかる部分をCで書き始めて、ctypesでインターフェースを作った。最終的にはPython APIを使って書き直したんだけど、Cで書いた部分が多すぎて、なんで全部Cで書かなかったんだろうって自問自答したら、「Cが得意じゃないから、壊す自信がない」って答えが返ってきた。だから今はRustで少しずつ書き直してる。主にRustを学ぶためにね。長くなったけど、外部ライブラリの機能がコアのPythonコードを超え始めたら、それは多分、全部別の言語で書くべきだってサインだと思う。

私はPythonのツールがPython以外の言語で書かれるのには完全に反対です。C拡張が存在するのは理解してるし、ほとんどの場合、PythonはCPythonと同義です。 >2つの言語で十分だと思う。誰も求めていない3つ目は必要ない。何のために十分なの？uvユーザーはそれに悩まされる必要はないよ。ほとんどのエコシステムはツールに対して言語のミックスを使ってる。ツールのユーザーが心配するような細かいことじゃない。 >理由もなく既存のエコシステムに入り込むのには反対です。それはもっと速いから。Pythonで書かれてないからね。ツールはユーザーのためのもの。ツールの言語はツールの開発者のためのもの。これらは同じ人である必要はない。重要なのは、そのツールがエコシステムの中で実際の問題を解決しているかどうか（解決してるよ）。人々はそれを好きなの？

この視点には感謝だけど、uvのようなツールをRustで作るのは良いアイデアだと思う。なぜなら、それはPythonの管理をするためのツールであって、Pythonコードの中から呼び出すためのツールじゃないから。Python管理ツールもPythonで書かれていると、鶏と卵の状況が生まれる。まず、Python管理ツールを始める前に、動作するPythonのインストールが必要になる。おそらくそれを使うのは、他の方法でPythonの管理をするよりも優れているからだよね。そうなると、どのPythonのバージョンや特定の実行ファイルをこの管理ツールが使っているのか、実際に実行しているコードは同じものを使っているのか、依存関係ツリーはどうなってるのか、管理ツールが実行している環境で必要なPythonパッケージをどう管理しているのか、実行しているコードが完全に独立したパッケージ環境を使っているかどうかをどうやって確認するのか、もしそうじゃなかったら、アプリが必要とするパッケージやバージョンと管理ツールが必要とするものの間に衝突があったらどうするのか、これらのことがうまく機能していない場合、どうやってデバッグして修正するのか、などの複雑な問題が出てくる。管理ツールがコンパイルされたバイナリとしてダウンロードして使えるものであれば、どの言語で書かれていても、これらの厄介な質問は解消される。そうすれば、そのツールは実際にシステム上のPythonの使用に関するすべてを管理してくれて、ツール自体を管理するための別のツールチェーンを使う必要もなくなるし、そのツールが実際に使いたかったツールと衝突する可能性があるかどうかを心配する必要もなくなる。

「2つの言語で十分だと思う。誰も求めていない3つ目は要らない。」 githubでruffとuvがもらったスターの数を見てみて。これは急成長だよ。だからruffで評価されて、uvに進んだ。これを「求められた」と呼べるね。 > 「理由もなく既存のエコシステムに入り込むのには反対だ。」 それは理由があるよ。今あるツールはひどくて、Python以外の何かを書いたことがあるなら使えないから。: それを言うのは、誰かがそれに気づかない唯一の理由は、もっと良いものを見たことがないからだと思う。まあ、CやC++の方がひどいツールもあるけど、Pythonは最悪のツールを持っている言語のトップだよ。

「理由もなく既存のエコシステムに入り込むのには反対だ。」 理由があるよ。今日存在するツールはひどくて、Python以外の何かを書いたことがあるなら使えないから。: それを言うのは、誰かがそれに気づかない唯一の理由は、もっと良いものを見たことがないからだと思う。まあ、CやC++の方がひどいツールもあるけど、Pythonは最悪のツールを持っている言語のトップだよ。