Repository navigation
v0.11.0 jev-lint-curated の host の入れ替えを直列にし、後始末と要約の残りを片付ける
配布物の変更は skills/tooling/jev-lint-curated の10ファイル (追加2、変更8)。host の入れ替えを直列にし、Python の版で挙動が変わる stdlib の呼び出しを外し、後始末・TMPDIR・要約の残りを片付けた。skill 名、登録経路、コマンドの形は変わらない。これまで動いていた形のうち、相対の TMPDIR と、確かめられない host は終了コード2で止まるようになる。
消費側への影響: skills/tooling/jev-lint-curated — ISSUE-74, ISSUE-83
- TMPDIR が空でなく相対のときは、check・review・compat のどれも終了コード2で止まる。これまでは相対の値を cwd を基準に絶対化していたので、compat は一時ディレクトリを cwd (消費側のリポジトリであることが多い) の下に作り、check と review は置き場がリポジトリの中になるときだけ止まっていた。拒否するのは host の用意の後なので、compat では引数の版の取得を走らせてから止まる (ISSUE-74)
- host を取得するときは、置き場 ($XDG_CACHE_HOME か ~/.cache の下の jev-lint-curated/) に版ごとのロックファイル .lock-<版> を作って残す。同時に走った実行は、どちらかの取得が終わるのを待ってから、置かれた host を再利用する。これまでは同時の取得で、良い host を消して空のまま残す経路と、偽の終了コード2になる経路があった。再利用できる host があるときはロックファイルを作らない (ISSUE-74)
- host やその祖先、展開した木の設定ファイル、--json-out の保存先を、権限などで確かめられないときは、どの Python の版でも終了コード2で止まる。これまでは版で挙動が分かれ、たとえば Python 3.14 では読めない host を「無い」と読んで取り直そうとした (測った 3.14.7 と 3.9.6 で同じ挙動になることを確かめた。3.13 は測っていない) (ISSUE-83)
- 要約の文面が変わる。dry-run の見積もりは「費用 $X (1 パス分。3 パスで最大 $Y)」になる (上流の見積もりは 1 パス分で、ラッパは常に 3 パス聞く。実測では実行の費用が見積もりの約2.5倍だった)。未回答の行には、記録で答えの無い subject のファイルごとの件数が付く (例: 未回答: 133 件 (scripts/test_check_issue_closure.py 133))。要約の文字列を読んでいる消費側では形が変わる (ISSUE-74)
- check -- -x のような - 始まりの位置引数は引き続き終了コード2で止まるが、エラーの文面と止まる時点が、パスと版の検査の側 (git の後、host の前) のものになる (ISSUE-74)
- nohup の下のように SIGHUP が無視されている環境では、SIGHUP で中断しなくなる。これまでは無視されていても後始末に入って終わっていた (ISSUE-74)
- 展開した worktree を消し切れなかったときの告知の文面が変わり、prune が成功してもディレクトリが残ったときにも告げる。この版の SKILL.md の後始末の節は、まだ古い手順 (git worktree prune で消す) のままで、それだけでは登録が残る。ディレクトリに .git が残っている間は prune が登録を消さないため。残ったときは、展開の一時ディレクトリ (一時ディレクトリの置き場の下の jevlint- で始まるもの。worktree はその中の tree) を消してから、本体のリポジトリで git worktree prune を実行する。SKILL.md は PR #78 で直し、次の版に入る (ISSUE-74)
- scripts/ には本体6本とテスト6本が入る (jevlint_fs.py とそのテストが加わった)
--allow-build=@ast-grep/cli を付ける理由と、@ast-grep/cli の postinstall が走ったかの確かめ方を、コードのコメントに書いた (挙動は変えていない)。pnpm 12.3.4 で macOS arm64 と Linux x64 を測った結果で、走ったかは ast-grep --version の終了コードでは分からず、パッケージの中の ast-grep がネイティブのバイナリか Node のスクリプトかと、stderr の警告で見分ける (ISSUE-74)。
確かめたこと: テストは CI (ubuntu-26.04 の Python 3.14.4) と手元の Python 3.14.7 と 3.9.6 で通る。host の入れ替えは、2 つのプロセスを同時に走らせて取得が 1 回になることを、テストの外で確かめた。キーを使う check はこの版では走らせていない。配布経路 (pin を上げた消費側の Skill ツールからの読み込み) での確認は、このリリースのあとで消費側で行う。
同伴: CI の runner を ubuntu-26.04 に固定し (ISSUE-82)、python-tests の job で python3 の版を出すようにした (どちらもリポジトリの CI だけの変更)。リポジトリのテストで Python の版により期待値を分けることを、scripts/test_run_python_tests.py の検査がリポジトリ全体で禁じるようにした (ISSUE-83)。docs/issues/ の変更 (ISSUE-81 から ISSUE-84 までの起票、ISSUE-81 の結果の記録、ISSUE-81 / ISSUE-74 / ISSUE-82 / ISSUE-83 / ISSUE-84 のクローズ) と、Python テストの manifest を直した。
commit range: v0.10.0..bb12438 (7 commits)