たまには本業に関連することを。
背景
2025年現在のPythonパッケージマネージャはuvが第一選択肢だと思ってて、
というのも、一時期一世を風靡したRyeは開発が止まって、公式に「uv使ってくれ」ってアナウンスされたし、
uv、Ryeの開発元がRuffを開発してるので、「死なば諸共」?「毒を喰らわば皿まで」?の精神で、魂を売り切った方が良いと思ってる。
uvに魂を売る前は謹製のvenvでrequirements.txtを使ってた。
PEP 621でpyproject.tomlの仕様が固まったのは2020年で、その頃にPoetry越しにpyproject.tomlを触り始めたけど、
そもそもシステムやアプリを開発するのが圧倒的に多く、他人様に使わせるライブラリを開発するようなことはほとんどないので、恩恵を感じることがほとんどなかった。
今、uvに落ち着いた状態でも、正直その辺のビルドシステムやパッケージングの統合に関する恩恵は全く感じてなくて、シンプルに「まぁ、標準化仕様に沿っておきましょう」で使ってる。
直近、しばらくTypeScriptでReactな界隈の仕事が続いて、
「Node.jsの世界はライブラリの新陳代謝が早すぎる…(小並感)」と目を回しながらPythonの世界に帰ってきたら、
「Pythonの世界でも依存ライブラリの更新はそれなりに対応していかないと、技術的負債に直結だなぁ」と認識を改めることになり、
ncu的なの使えば、チョチョイのチョイでしょ、と舐めた態度でいたら、全然ない。
一応、自分で調査した範囲では2019年で開発が止まってるpip-upgraderと、requirements.txtだったら使えるpurは見つけた。
uvは uv sync --upgrade
というコマンドで、pyproject.toml内のバージョン制約に則りつつ最新バージョンを一括インストールはできるんだけど、pyproject.tomlを書き換えないので、
uv.lockを見たりしないと、結局どのバージョン使ってるかはわからないし、メジャーバージョンのアップデートに追随できない。
ちなみに、 pip list --outdated
で古いバージョンを一覧することは簡単にできる。
折しも昨今のAI(LLM)ブームで、「ライブラリの更新なんてAIにやらせりゃ良いでしょ」と思われがちなんだけど、
つよつよLLMでも学習データは1年半前とかザラなので、「最新バージョンを調べる」みたいなタスクは苦手。
かなりしつこく「公式レポジトリで最新バージョンを確認してこい!」って言っても、ダメな時があるぐらい。
(Vibe CodingとかAIアシスタントについては、実践してみていろいろ思うところもあり、また別にエッセイとして書き残したい)
成果
ないわけがない、と思いつつも調べる時間と作る時間を考えたら、作ったほうが早そうだったので、作った。
#!/bin/bash
# update-deps.sh
echo "🔍 Checking for updates..."
# 一時ファイルに現在のdependenciesを抽出
grep -A 100 "dependencies = \[" pyproject.toml | grep '"' | while read -r line; do
# パッケージ名を抽出
pkg=$(echo "$line" | sed -E 's/.*"([a-zA-Z0-9_-]+).*/\1/')
# 最新バージョンを取得
latest=$(uv pip index versions "$pkg" 2>/dev/null | grep "Available versions:" | cut -d: -f2 | cut -d, -f1 | tr -d ' ')
if [ -n "$latest" ]; then
# pyproject.tomlを更新
sed -i.bak -E "s/(\"$pkg[^\"]*)[0-9]+\.[0-9]+\.[0-9]+/\1$latest/" pyproject.toml
echo "📦 $pkg → $latest"
fi
done
echo "✅ Done!"
所感
いきなりpyproject.tomlを更新するんじゃなくて、一覧表示だけして、「これらのアップデートに対してBREAKING CHANGEがないか調査して」ってLLMに投げれる仕様の方が良いかも。
まぁ、その辺はdiff取れば良いか。
GitHubにあげてdependabotに任せる、って手もあるんだけど、経験上、ライブラリを単体で更新していく作業は別の弊害を招くことがあるので、まとめて更新作業をしやすくする方に賭けてみた。