uvとPEP 723の衝撃 virtualenvはもういらない？
引用元：https://news.ycombinator.com/item?id=44369388
uvのおかげでPythonスクリプトが仮想環境探し回らなくても「そのまま動く」感じになってきたの、マジ助かる！
あとは誰かシェルスクリプトでも同じことやってくんないかな。シェルの依存管理とか再現性とか、いまだに石器時代だよ。curl|bashで祈るか、README見て12ステップ手動でやって3つくらい依存が足りないか…なんてザラ。
まあNixとかあるけど、時間の概念とかNixマニュアルを超越してないと無理だし。Docker？ sed動かすためにLinuxディストロ丸ごとダウンロードとか冗談でしょ。
シンプルで宣言的、そして人間向けな中間点、絶対あるはずなんだよ。
＞パッケージング、依存管理、再現性がシェルの世界では石器時代
個人的にはそれで良いと思うんだよね。そういうのが必要なスクリプトは、もうシェルを使うべき範囲を超えてるから。シェルスクリプトは小さく、20行くらいで十分。言語自体がクソすぎて、それ以上大きくする価値ないよ。
Nixはこのユースケースならそんな難しくないと思うな。他のディストロにインストールも簡単だし、入っちゃえばこんな感じに書けるよ。
#! /usr/bin/env nix-shell
#! nix-shell -i bash -p imagemagick cowsay
# scale image by 50%
convert “$1” -scale 50% “$1.s50.jpg” &&
cowsay “done $1.q50.jpg”
NixOS全体とかパッケージングは確かに大変だけど、シェルスクリプトに使うだけなら悪くない。
俺の経験則だけど、if文を書き始めたらそれはもうbashからPythonとかNodeに乗り換える時期なんだよ。if文の細かいニュアンスを毎回調べるなんて御免だね。
シェルスクリプトの依存管理問題を解決できれば、新しい言語機能とかも使えるようになるし、POSIXとかの制約からも自由になれるんだよね。例えば、うちのチームが使うシェルスクリプトは、プラットフォームに関係なく全部GNU coreutilsを使ってる。sedの挙動の違いとか気にせず、GNU sed向けに書けば「そのまま動く」んだ。別にそれが絶対必要かって言うと違うけど、そういう制約なしで書けるのは気持ちいいよね！
もっとインターフェースがきれいなコマンドとか、統一されたシンタックスのコマンドを選べるようになる。
＞言語自体がクソすぎる
外部プログラム呼び出すなら、シェル以外にマシなのないんだよな。他の言語だとクソ面倒。まあそれはそれで良いのかもしれないけど、大きめのシェルスクリプトを他の言語で書き直すと、元の20行が400行になっちゃったりしてイライラするんだ。
君の言うこと、まあ同意するよ。POSIX系のシェルはシンタックス多すぎなのにパワー不足。でも俺が本当に欲しいのは「より良いシェル言語」なんだ。他のインタープリタ言語に置き換えるんじゃなくて。
心を込めて言わせてもらうよ。俺のArch Linuxが壊れてNixを試したんだ。一番衝撃だったのはnix-shell（他のディストロでも使えるのは知ってるけど聞いて！）。一度きりのためにプロジェクトをインストールするのがマジクールなんだ。
デスクトップ録画したい？ 俺にとってはそんなに頻繁にやるタスクじゃないし、Archだとobsを依存としてシステムアップデートしなきゃいけないか、毎回アンインストールしなきゃいけないのが嫌だったんだ。ephemerality（一時性）って概念をNixで求めてたんだよ。新しいソフト試したり、ホームシステムをミニマルに保ちたいタイプだからね。最高！
nix-shell -p obs-studio & obs ってやるだけで完了だよ。正直Nixには惹かれるところがたくさんある。まだflake周りは全然だけど、サンドボックスとしてコード実行に使うアイデアをRedditで見つけて、これで何か面白いことやろうと思ってる。（Codapiみたいなの作りたい。Codapiの作者さん、もし読んでたら話したいです！）
まるでプラグアンドプレイみたいにできるソフトがある気がするんだ（HetznerがNixOSマシン提供するの想像してみて！ 今はまだ不安定らしいけど）。HetznerでNixOSマシンを使える方法ができれば、Dockerみたいな分離なしでDigital OceanのDroplets/プラグアンドプレイにめっちゃ近いのができる気がするんだ。DockerにはDockerのユースケースがあるだろうけど、Docker管理するよりNixの方が簡単だと個人的には感じてる。俺がNix使ってて感じてること言ってるだけだから、遠慮なく訂正してね。
あと機能的なLua（fxn Luaとかあるの？）からNixへのトランスパイラとかあったら良いな。システム管理をNixじゃなくてLuaで書きたいんだ。でもNixもまあ良いんだけどね！
＞uvのおかげでPythonスクリプトが仮想環境探し回らなくても「そのまま動く」感じになってきた
うーん、最後にチェックした時、uvは~/.local/share/uv/python/cpython-3.xxにインストールされるんだけど、ミニマルなDockerみたいに他のPythonがない環境にグローバルにはインストールできないんだよね。
だから基本的に、結局venvの中で動いてるってこと。
if文にどんなニュアンスがあるっていうんだ？
例えばbashのif文は、単にコマンドを実行して、その終了ステータスに基づいて2つのコードブロックのどちらかを実行するだけだろ。終了ステータスが真ならthen以降を実行、偽ならelse以降を実行する。（elsifは確かに余計なシンタックスだけど—elseの中にifが入ってるだけならもっと良かった。）これは他のプログラミング言語とかなり似てるし、そんなに覚えることないように見えるけどな。
確かに俺もシェルスクリプトで「偽のシンタックス」は避けてる—[とか[[は絶対に使わない。これらは単なるコマンドなんだって構造を分かりにくくしてるだけだから。代わりにtestって書くんだ。これは単なるコマンドだって明確にするし、何してるか分からなくても、同じシェルでman test, help test, info testとか実行すれば分かるってことを示唆してる。if文やif式は少なくシンプルに保つべきってのは同意だ。でもこれは実は他の多くの言語よりシェル言語の方が簡単にできる場合がある！ &&や||をチェーン接続するだけで、ネストされたif文どころか、どんなif文も使わずに結構なスクリプトを書けたりするんだ。
いいね、でもそれをフリートにインストールできる保証があって、そのフリートが100% Linuxで、AIXもHPUXもSOLARISもIBM Power上のSUSEもない、なんて状況ならね…。
そういう経験あるよ、試したけど、盛大にコケた。
uvのシステムサイトパッケージについての設定はこれ見てね。
https://docs.astral.sh/uv/reference/settings/#pip_system
やっほー、Hetznerに言及してたからここで返信しようと思ってさ。NixOSはクラウド製品の標準イメージにはないけど、ISOライブラリにはあるよ。お客さん側で手動インストールできるんだ。やり方は、クラウドサーバー作って、クリックして、メニューの”ISO”を選んで、リストをアルファベット順に見てみてね。–Katie
あー、それやったわ。もうあんなキチガイじみた状況に対処しなくていいなんて最高。担当してたビルドファームでは、LinuxやBSDの箱で作業する時はいつも楽しかったな。AIXとHPUXは物投げたくなるレベル。Itaniumのクソみたいなやつも遅いだけで、普通のサーバーっぽかったし。もう二度とLinux＼BSD以外のサーバーなんて自ら扱わないわ。
それは残念。俺はまるで修行僧レベルのPython柔術マスターだったのに。どんな問題も解決できたんだぜ、HTTPSの悪夢とか、brewとpyenvのバージョン問題とか、virtualenvのやらかしとか。でも今じゃ、この知識全部時間の無駄だわ。
てかさ、uv python installをシステムワイドに入れるにはどうすればいいの？何やっても~/.localへのシンボリックリンクにしかなんねーんだけど。
違いは、俺が知る限り[[が本当の構文ってこと。確かこれで特定の問題を避けられたり、エラーメッセージが分かりやすかったり、bashのビルトインだって確実だったりするんだよな。もっと心配なのは、これを使うとshとの互換性がなくなることかな。
＞uvでPythonをインストールしても、グローバルでは使えません（pythonコマンド経由とか）。この機能はプレビュー中です。詳細はInstalling Python executablesを見てください。
＞uv runを使うか、仮想環境作って有効化すれば直接pythonを使えます。
だそうだ。
絶対なんて言うなよ。Pythonのエコシステムって色々変わるから、uvだって別の何かに取って代わられる可能性は十分ある。今回はなんか違う感じもするけど、しばらくは分からないだろうね。
だって、if文の書き方だけでもtest、[、[[って3つも同じくらい有効な方法があるんだぜ。後ろ2つについては、ファイルや条件をテストするためのシングルレターのフラグがいっぱいあってごちゃごちゃしてるしな[0]。何をもって”偽の構文”って言うのか俺には分かんないけど、bashのことはそんなに知らないし。
調べるなら全部それなりに理解できるけど、スクリプトはすぐに分かりにくくなる。条件分岐ってこんなに難しくあるべきじゃないだろ。
[0]: https://tldp.org/LDP/Bash-Beginners-Guide/html/sect_07_01.ht…
Homebrewでいけるんじゃね？
miseってのチェックしてみてよ。https://mise.jdx.dev/
俺たちの$workでは開発環境管理にこれ使ってるんだけど、DockerとかNixよりずっと楽なんだ。しかも並列でインストールできるから、普通のDockerfileより断然ボーナス高いぜ。
ターゲットOSにプリインストールされてないバイナリやライブラリを使うshellスクリプトなんて、俺は絶対に書かないんだよね（それが正しいターゲットってもんだし、移植性のあるshellスクリプト書くなんてバカげてるよ）。
macOSでしか存在しないコマンドを使うスクリプトを、Linuxで動くようにしてくれるパッケージマネージャーなんてないんだから。
前にチェックした時、これは凄くうまくいくんだよね。ただし、imagemagickとかcowsayの特定のバージョンにこだわらない限りだけどね。
もしこだわるなら、nivとかflakesとかについて学ぶハメになるよ。
［0］：正直言うと、3年くらい前の話だけど。
Nixは、できること全部に対して、やりすぎなんだよね。シンプルでポータブルなスクリプトを書くのも例外じゃない。
でも：何をするにも同じスキルセットで済むんだ。だから、投資する価値はあると思う。もし一つのことだけに使うなら、価値はないかもね。でも一度学べば、どこでも活用できるんだ。
依存関係があってもなくてもPythonスクリプト、uvがあってもなくても（めっちゃ推せるuv2nixを使えば。俺は関係ないけど）、好きな依存関係を持つbashスクリプトとか、突然それが自分で選べるようになって、実際に適切なツールを選べるようになるんだ。
話脱線させたくないけど、この文脈では関係ある気がするんだよね。これら全部のちょっとしたパッケージングの問題がNixで消えて、たった一つの巨大な問題に置き換わるんだよ XD
当時（10年前）は、ありとあらゆる種類のデプロイ先を持つ巨大な顧客がいる会社で働いてたよ。今ではそのリストはだいぶ短くなってると思うな。
彼らのためにも、そう願ってるよ。ぞっとするね。
思わず言いたくなっちゃうんだけど、明らかに解決策は、依存管理、依存関係、再現性が理論上マックスになるように、Dockerの中でNixをshellとして実行することだよね。
残念ながら、たとえ最もシンプルなスクリプトでさえ動く保証はまったくないんだ。
#!/bin/bash
make ＄1
これには複数の問題が考えられるね。
俺、1000行以上のBashプロジェクトをいくつか持ってるんだ :) サイズを大きくしたわけじゃないんだけど、めっちゃ読みやすくてメンテナンスしやすいよ。機能も全部揃ってるし、ちゃんと動く（tm）。他の言語だったら、たぶん1000行より長くなるか、メンテがもっと大変だったかもね。外部プログラムをいっぱい呼び出すから、shellスクリプトにこだわったんだ。
歴史的に見て、俺の経験則は、スクロールしないとスクリプト全体が見えなくなった瞬間に、Pythonとかansibleで書き直すってことだな。書き直しは考えるけど、実際やるまでにはたいてい時間がかかるんだ（もしやるとしてもね）。
これめっちゃいいね！最近流行ってるみたいだ。simonwのブログhttps://simonwillison.net/2024/Dec/19/one-shot-python-tools/で初めて見たよ。3月には別の記事でもHacker Newsで議論されてたんだ（https://news.ycombinator.com/item?id=43500124）。このトピックがもっと広まるように、フロントページに長く載ってるといいな。
わかる！このテクニックいいよね。記事の最後でYouTubeのチャンネル登録者数を取得する例が出てたけど、simonwのLLMを一部使って似たの作ったんだ。よかったら使ってみて。
llm -f youtube:＜id＞
llm -f yt:＜lang＞:＜id＞
ここにコードあるよ → https://github.com/redraw/llm-fragments-youtube
もっとコメントを表示（1）
記事の作者さんと同じで、俺も仕事でも家でもGoじゃなくてPythonでクロスプラットフォームの使い捨てスクリプトとか個人のツール作るようになったよ。Pythonの型チェックがクソなのが残念だけどね。tyとかpyreflyとかが出てきて状況が改善されるのが楽しみだ。
スピードもそうだけど、型システム自体も別問題だよ。Pythonの変な型システムを理解し始める前に、だいたい5〜10個くらいの問題にぶつかるのは確実だね。
Pythonの型チェックが”クソ”だとは思わないな。pyrightはほぼ完璧だよ。Django用とかの非標準の型には対応してないけど、それはメンテナーの意図的な決定だし、それが標準の型をもっと表現豊かにする努力を促したんだと思うからよかったと思ってる。
Rustベースの型チェッカーが成熟するのも楽しみだけど、それは型チェックの速度が桁違いに改善される可能性があるからであって、Pythonの型チェックが”クソ”だからじゃないんだ。
確かに、Python本体が出してる型チェッカーが（Djangoとか使わない限り）二流で、Djangoとか使うと一流になるってのは、外部の人にはわかりにくいだろうけどね。
俺は正直Goをクロスプラットフォーム開発で好きになったことないんだよね。いつもUnixにがっちりくっついてる感じがしてた。PythonもWindowsだと結構問題あるけどね。俺の人生、長い間ライブラリの変な.DLL問題のデバッグで詰まってたよ。
変な話だけど、それが理由で、個人的なクロスプラットフォームアプリはゲームエンジンで作るようになったんだ。
コミュニティがtyみたいに一つの型チェッカーに収束してくれるといいな。複数の型チェッカーがあるって事実が、言語全体にとって本当に邪魔になってると思うよ。
uvはちょっとしたサイドプロジェクトに使うのに最高だね。uv runと『uv tool run』、つまりuvxを組み合わせると、GitHubからPythonスクリプトをめちゃくちゃ簡単に持ってきて、VM内でインストールして実行できるんだ。git cloneもvenv作成＋activate＋pip installもいらない。
それにuvは速い—マジで速い。あまりに速すぎて、何か失敗してサイレントエラーしたんじゃないかと思うくらいだよ。実際には求めてたこと全部やってくれてるのに、pipの10倍速いんだ。
ちょっと（特にドキュメントが）洗練されてない部分はあるけど、大胆だし十分良いから、それでも使う価値あるね。
本当にね。uvはどういうわけか、pyenvが–helpを出力するより速く依存関係を解決してインストールするんだ。
Pythonの起動が遅いのは、importのたびにfilesystemの広い範囲をスキャンして解決しなきゃいけないとか、ちゃんとした理由があるのは知ってるよ。でもGoとかRustで実装されたツールみたいに、ミリ秒以下の起動時間で作業できると、本当に新鮮な気分になるんだよね。
ヘルプ表示のためだけに全部importする必要はないんだよ。CLI引数をパースした後までトップレベルのimportは避けるようにしてるから、それまではargparseかclickだけがimportされる感じ。こうすれば、Pythonでも起動が瞬時に見えるよ。
例：
if name == ”main”:
from myapp.cli import parse_args
args = parse_args()
# -hが指定されてたらここでプログラムは終了するよ
# ここで重いimportをする
from myapp.lib import run_app
run_app(args)
でも別のパターンとして、トップレベルのツールがpkg_resourcesとentry_pointsを使って、そのコア機能を動詞プラグインに切り出してる場合がある。そのケースだとヘルプ表示が実は最悪のシナリオなんだ。利用可能なプラグインを探すためにfilesystemをスキャンしなきゃいけないだけでなく、それぞれのヘルプ文字列を聞くために全部importする必要があるからね。
この極端な例がROS 2ワークスペース用のcolconビルドツールだよ：
https://github.com/colcon/colcon-core/blob/master/setup.cfg#…
驚くことじゃないけど、これの起動時間は良くないんだ。
Pythonのスピード批判の流れを脱線させるつもりはないんだけど、pyenvはbashで書かれてるよ。色々なバージョンのPythonをインストールするためのツールなんだから、既にPythonがある前提だとおかしいでしょ。
おお、それが実は遅い行出力スピードの理由を説明してるのかも。ありがとう、長年のちょっとした謎が解けてスッキリしたよ :)
Pythonの起動遅延の話は理解できるんだけど、pyenvが”usage”出力（–helpで表示されるやつ）の各行を出力するのに時間がかかるのが本当にわからないんだ。もう明らかにそれだけをするコード分岐に入ってるのに。まるで各行が出力される間に重い作業をしてるみたい！そんなCLIツール、他に知らないな。
pyenvの起動が遅いのは、ラッパーシェルスクリプトとPythonの起動時間が影響してるんだよ。
その”遅さ”と、「俺のコンピューターでは動く」Pythonプログラムを別のコンピューターで動かそうとする完全な”狂気”にうんざりして、自分のPythonツールは全部Goで書き直したわ。ユーティリティの約95%は、実行環境に合わせてクロスコンパイルされたGoのバイナリになったよ。残り数個はGoにまだ利用できない、または十分に成熟してない（API）ライブラリを使ってるから。
最後に見た時、pyenvの開発者たちはその理由（遅さ）でコンパイルされたラウンチャーの実装を検討してたらしいよ。でも俺にとってはもう終わった話で、uvに乗り換えたけどね。
uvがすごいのは同意！でもあれはvirtual machineじゃなくてvirtual environmentだよ。ハードウェア仮想化なしでOS上でスクリプトを動かすんだ。virtual environmentはPythonの依存関係だけを隔離するんだよ。
＞uv（特にdocs）はlittle rough around the edgesだけど、bold enough and good enoughだから使う気になったよ。自分だけかと思ってた。more examples showcasing different use casesがあればniceだと思うからissue openしようと思うんだ。
No more dependency problems with mkdocs！uvx –with mkdocs-material –with mkdocs-material-extensions –with mkdocs-nav-weight mkdocs serve -a localhost:1337 ってやったら、毎月困ってたdependency問題がなくなったんだ。
Funnily enough、なんかfasterになった気もするよ。
Is there a reason you didn’t explicitly pull in mkdocs as a dependency in that invocation？ I guess uv will expose it/let you run it anyways due to the fact that it’s required by everything else you did specify.
its a uvx callだよ。the tool being invokedはmkdocsで、all the other dependenciesはadditionsなんだ。
Very nice！ Rustもdoing something similar tooで、single-file shell-type scriptsでdependency management includedするideaをそこで知ったんだ。Hopefully more languages follow suitするとusefulで、passing gists aroundとかsmall programs書くのにいいよ。[0] https://rust-lang.github.io/rfcs/3424-cargo-script.html
C# tooだよ: https://devblogs.microsoft.com/dotnet/announcing-dotnet-run-…
＞Before this、one-off scriptsにはGoがpreferだったよ。single binaryでstatically linked、third-party libsほぼ不要、network callsにstdlibがbetter、tooling（formatter, pytestいらない, go vet）もbetter、Easy concurrencyだから。uvはgreat improvementだけど、Python scriptsを書かないのはtooling以外のreasonsもある。standard toolじゃないし、JS ecosystemでscarred and tiredだから、stable, reliable, boring toolsが好き。Right now, Goでenoughだよ。
I needed to process a 2 GB xml file the other day. My Python scriptがchugging awayしてる間に、Claudeにtranslate it to Goしてもらったんだ。The vibe-coded Go programは、original Python scriptがterminateする前にprocessed the fileしたよ。That was the first time I ever touched Goだったけど、certainly won’t be the last。
Go is pretty awesome. scriptにsome timeかけたら、at least 50 times faster than Pythonになっただろうね。
（author of post here）I still use both Go and Python. But Python gives me access to a lot more libraries that do useful stuff. For example the YouTube transcript exampleは、Goにはdecent libraryがないからPythonでonly possibleだったんだ。
ああ、それは確かにそうだね。仕事でPythonはいっぱい使ってるよ。言語は別にいいんだけどさ、ツールの使い勝手がまだ30年前みたいなんだよな。
＞前は使い捨てスクリプトにGoをよく使ってたんだ、自己完結型のバイナリが簡単に作れたからね。
ほら、こうやって関連してるんだよ:)
もう10年近くPython開発してるけど、依存管理が問題なんて思ったこと一度もないよ。どんなデプロイ環境でも”スクリプト”動かすときは、その環境のPythonシェルでやってたしね。だから、何そんな騒いでるのかまだよく分かんないな？すごくでかいPythonコードベースで仕事してるけど、uvに移行して唯一メリットあったのは依存インストールが速くなったことで、ローカルとCIのセットアップ時間が改善したくらいだよ。
もっとコメントを表示（2）
他の人とか初心者には、どうやってあなたのPythonコードを実行させてたの？（それか、5年以上前の古いプロジェクトを自分で動かすときはどうしてた？）
スクリプト実行＼”missing x…”＼pip install x
スクリプト実行＼”missing y…”＼pip install y
＞ y not found
yをググってパッケージ名を探す
pip install ypackage
＞ conflict with other package
venv忘れてシステムPythonを汚染したことに気づく
pip helpを見てアンインストール方法を思い出す
システムPythonをクリーンアップ
カレントディレクトリでvenv作成
最初からやり直し…
＼end of time＼
＞realize I forgot a venv and have contaminated my system python
＞check pip help output to remember how to uninstall a package
＞clean up system python
＞create venv at cwd
＞start over
これ、怖いくらい身に覚えあるわー。
なんかさ、仕事するためにコンピュータの電源をつけなきゃいけないって文句言ってる人を見てるみたいだよ。
ありがたいことに、最近のいくつかのシステムは、pipでシステムをいじろうとするとデフォルトでエラーになるんだ（システムのパッケージマネージャーを使うべきだってこと）。上書きするのは簡単だけど、うっかりミスでやらかすのを直す手間が省けるから助かるよ。
Pythonの依存管理は、他のほとんどの主要な言語と比べると、ごく最近までひどかったんだよな。
みんな「Python dev」とか「JS dev」って考え方やめて、他の言語も試してみようよ。GoとかRust、JS見ればPythonの依存管理がどれだけ混乱してるかわかるから。多くの言語で体験がもっとシンプルなんだ。このツールのカオスと仮想環境の複雑さは、初心者には大きな壁だね。初心者だけじゃなく、Armin Ronacherみたいなベテランも文句言ってるしね。
uvは正しい方向への大きな一歩だけど、GoのツールやRustのCargoみたいに、基本的なツールが言語バイナリに組み込まれてない限り、新しいツールがどんどん出てきて、さらにバラバラになっちゃうのが問題だよ。
混乱してるって言うのは控えめすぎだよ。それはPythonの依存管理がちゃんと動いてるけど複雑なだけ、って意味になっちゃうじゃん。でも実際はうまく動いてないんだ。ロックファイルみたいなものがなくて、再現性のあるインストールが運任せになってる。小さなスクリプトならまだしも、チームで作業したりサーバーにデプロイしたりするなら、決定的なビルドが必要なのに、まともなパッケージマネージャーがないとそれは絶対不可能だよ。
uvみたいなツールは、「手元の環境では動く」問題を解決してくれる。それに信じられないくらい速い。
ロックファイルはもう存在するよ。
https://packaging.python.org/en/latest/specifications/pylock…
問題は、標準化されたビルドツールがないこと（pipやuvはどっちもサードパーティ）。だから、Goのgo.modとかRustのcargo.tomlと違って、このロックファイルを生成する方法が山ほどあるんだ。だから多くの場面で機能しないし、めちゃくちゃ混乱するんだよね。
私の考えだけど、私は何よりもまずエンジニアなんだ。だから目の前のタスクにとって一番良いツールを使うようにしてる。それは他の人がプロジェクトで作業する上でのビジネスにとっても一番良いものって意味ね。これがPythonと何かしらのフレームワークを使うってことになってる。
もっと速いかもしれない他の言語を使うべきだって言う人もいるけど、ビジネスが常にみんなで一緒に作業するのに一番良いものを選択するんだ。
そうだね、ビジネスの種類や成熟度、それに現地の才能の有無にもよるよね。PythonとDjangoで始めて、ビジネスが拡大するにつれて他のテクノロジーに移行した会社を3社知ってるよ。そういう環境では、「Python dev」でいたい人と、すぐに新しい言語に適応できる人の二種類がいた。後者のグループの方がうまくやってたね。
「Python + Framework + Postgres」っていう主張で嫌なのは、文脈が欠けてることが多いこと。これはビジネスを始めてPMFを見つけるにはすごい組み合わせだよ。でも、PythonとPostgresが100k RPSとかペタバイト規模のデータの下で完全に壊れるのを見たことがないと、言葉だけじゃその限界を理解するのは難しいんだ。Pythonは素晴らしいけど、限界はあるし、全然機能しないケースもある。この「どこでも単一言語」っていう考え方が、JavaScriptがバックエンドやデスクトップに使われるようになった原因だよ。
誰でもPythonは書けるし、LLMがあれば、単一言語を知ってるだけじゃ大した強みにならない。他の言語にも親しんで、視野を広げるのはいいことだと思うよ。もちろん、PythonやJavaScriptでうまくスケールするビジネスもある。でも私が言いたいのは、Pythonを捨てろってことじゃない。他の言語で経験を積んで、Pythonのビルドツールが批判された時に、その懸念に心から共感できるようになることなんだ。そうじゃないと、ほとんどPythonしか使ったことない人からの「Pythonのツールは大丈夫」みたいなコメントは、真面目に受け取れないね。
＞いつもそのENVのpython shellでやってる
環境がセットアップされてない時はどうするの？私は正直、全然Pythonの専門家じゃないんだけど、そこがいつも面倒だったんだ。uvxがあるとそれがすごく楽になるよ。
Pythonの前にPHP/JS/Javaを書いてたよ。Pythonももう10年近くやってるけど、4dregressさんと同じで、依存管理であまり困ったことはないな。JSとPHPはいろいろ問題があったけど、MavenとGradleはまだマシだった。Pythonでは、必要なものが実装されてるPEPを見つけたり、シンプルなワークフローやパッケージング戦略を考えたりすることで、ほとんどの問題は解決できたと思う。
最近は普通にpython venv/bin/＜some-executable＞とか、conda run -n ＜some-env＞ ＜some-executable＞を使ってるか、Singularityコンテナにパッケージしてる。uvについては色々良い話を聞くけど、私の仕事は研究で公的資金を使ってるから、できるだけオープンソースと標準を使おうとしてるんだ。私の理解では、uvはまだ企業に支えられてるし、前に確認した時（PEPの議論とかGH issuesで）は、私が必要なPEPを実装してなかった — たとえ実装してたとしても、もしその会社がビジネスモデルを変えたら（例えばAnacondaが数ヶ月前／年前にやったみたいに）、ビルドを更新するために研究予算を使わなきゃいけなくなるのを避けるために、たぶんシンプルなpip/setuptoolsを使うだろうね。
余談だけど、Singularityコンテナは研究やHPCにも便利なんだ。単一のアーカイブになるから、ネットワーク経由でたくさんの小さなファイルをロードするより、私が作業してるGPFSやLustreFSみたいな分散ファイルシステムでロードするのが速いんだよ。
仮想環境を作る：
python3 -m venv venv
仮想環境を有効にする：
source venv/bin/activate
仮想環境を解除する：
deactivate
それとも、uvx ruff
毎日Pythonを使わない人にとって、どっちの方が実行しやすいかな？
数年後に覚え直さなくていい方だろうね。
virtual environmentsをそんなに頻繁に使わないなら、毎回やり方を調べる方がまだ楽だよね。
Python devとして30年近くやってるけど、uvはdependency managementの多くの面倒な部分を取り除いてくれてると感じるよ。だから“問題”って言葉は違うかもね。troubleなくdependency managementの問題を解決できたことも多いけど、かなりの時間も費やしたんだ。10年近くは他の人のPython環境をproduction systemsで管理してたけど、それは大変な混乱だったよ、特に更新とセキュリティを確保しようとするとね。uvのすごさがわからないなら、それはおめでとう。かなり孤立した環境にいるみたいだね。でも断言するけど、uvはすごく騒ぐ価値あるよ、俺たちの人生をすごく楽にしてくれてるから。
Virtual environmentsだけでは不十分だよ。決定的なbuildは保証されない。production environmentがlocal dev environmentと同じcodeを実行することをどうやって確保する？uvやpoetryのようなdependency managersなしで、その問題をどう解決してるの？
じゃあ、4年経つ大きなprojectがあって、それを新しい.venvで動かすとしたらどうする？
今のところ、uv run --scriptでembedded metadataを使う時に、ちょっとだけ使いにくいと思ったことが一つだけあるんだ。スクリプトの変更をPython REPLでテストしたい時なんだけど、これをするのがちょっと大変で、こういうのを実行しないといけない:$ uv run --python=3.13 --with-requirements ＜(uv export --script script.py) -- python<br>＞＞ from script import X
もっと$ uv run --with-script script.py pythonみたいに使いやすいのがあったらいいな。
追記: こっちの方が良かった:$ ”$(uv python find --script script.py)”＞＞ from script import X
これでスクリプトの正しいpythonとvenvが立ち上がるよ。多分、スクリプトを一度実行してこれを作る必要があるかもね。
君が探してるのは多分これみたいなやつだと思う（重要なのは最後にREPL呼び出しを埋め込むこと）: https://gist.github.com/lostmygithubaccount/77d12d03894953bc…--interactiveとか好きなCLI flagをscriptから作れるよ。俺はよく小さいTyper CLIsでこんな感じの（または別のdev scriptで--sqlを使ってDuckDB SQL replに入る）ものを作るんだ。
どういたしまして。cat ~/.local/bin/uve#!/bin/bashtemp=$(mktemp)uv export --script $1 --no-hashes ＞ $tempuv run --with-requirements $temp vim $1unlink $temp
もし聞いてもいいなら、なぜunlinkじゃなくてrmなの？
