Dev

コードを書いているのはエディターとターミナルなのに、プルリクエストを出すときだけブラウザに移る。タブを探し、リポジトリのページを開き、「Compare & pull request」のボタンを押し、タイトルと説明を書き直し、レビューをお願いする相手を選ぶ。一つひとつは数十秒の作業でも、1日に何度も繰り返すと、そのたびに頭の中で組み立てていた続きが途切れてしまう。私が気になっていたのは、時間そのものより、この途切れのほうだった。 GitHub CLI、コマンド名で言えば gh は、GitHub が公式に配布しているコマンドラインの道具だ。git が手元のリポジトリと遠くのリポジトリのあいだで履歴をやり取りする道具だとすれば、gh はその外側にある GitHub 独自の仕組み、つまりプルリクエスト、イシュー、Actions の実行結果、リリースといったものをターミナルから扱うための道具になる。git の代わりではなく、git の隣に置いて使う。 この記事では、朝にブランチを切ってプルリクエストを出し、昼に CI の結果を待ち、午後にレビューをやり取りして、夕方にマージするまでの一日を、gh のコマンドだけでたどっていく。最後に、毎日使うための短縮の設定と、それでもブラウザを開いたほうが早い場面もまとめておく。 準備はインストールとログインの2つだけ エディターの隣にターミナルを置いておけば、プルリクエストの操作もそこで済むPhoto: Wikideas1 / CC0 インストールは、Windows なら winget install --id GitHub.cli、macOS なら brew install gh の1行で終わる。Linux でも主要なディストリビューション向けのパッケージが用意されている。入れ終わったら gh --version で版を確かめておく。gh は数週間おきに新しい版が出るので、手順の説明と手元の動きが違うと感じたら、まず版を新しくするのが近道だと思う。 次にログインする。gh auth login を実行すると、どの GitHub につなぐか、git の通信に HTTPS と SSH のどちらを使うかを順に聞かれる。認証の方法は、ブラウザでの承認を選ぶのが手軽だ。ターミナルに8文字の確認コードが表示され、ブラウザで GitHub の承認画面を開いてそのコードを入れると、ログインが完了する。ブラウザを使うのはこの一度だけで、受け取った認証情報は OS の資格情報の保管場所にしまわれる。 ログインできたかどうかは gh auth status で確かめられる。どのアカウントで、どこに認証情報が置かれているかが表示される。あわせて gh auth setup-git を一度実行しておくと、git の push や pull でも gh の認証情報が使われるようになり、パスワードやトークンを毎回聞かれることがなくなる。サーバーや自動化の仕組みの中で使うときは、ログインの代わりに環境変数 GH_TOKEN にトークンを入れておけば、gh はそれを読んで動く。 ...

新しい言語を触ってみようとするたびに、パソコンに何かが積み上がっていく。Python の版をもう一つ、Node.js をもう一つ、ついでにデータベースのクライアントも。数か月たつと、どれが何のために入れたものか分からなくなり、消してよいのかどうかも判断できなくなる。私の作業用パソコンも、しばらくそういう状態が続いていた。 VS Code の Dev Containers は、この積み上げを手元のパソコンではなく Docker のコンテナの中で起こすための仕組みだ。言語の処理系やコマンドはコンテナに入れ、エディターの見た目や操作はいつもの VS Code のまま使う。要らなくなったらコンテナごと捨てればよく、パソコン本体には何も残らない。設定は devcontainer.json という1枚のファイルに書かれるので、別のパソコンでも同じ環境を作り直せる。 この記事では、Dev Containers が何をどこに置く仕組みなのかを確かめたうえで、最小の4行の設定ファイルから動かし、道具を少しずつ書き足していく順番を追っていく。最後に、Windows で使うときにつまずきやすい点もまとめておく。 Dev Containersは、エディターの中身だけをコンテナへ移す 画面に見えているのはいつもの VS Code だが、Dev Containers では言語の処理系や拡張機能の多くがコンテナの側で動くPhoto: Pota12 / CC BY-SA 4.0 最初に押さえておきたいのは、VS Code が二つに分かれて動くという点だ。ウィンドウやメニュー、配色のテーマといった画面まわりは手元のパソコンで動く。一方、コンテナの中には「VS Code Server」と呼ばれる小さな本体が自動で入り、ファイルの読み書き、ターミナル、言語の補完やデバッガーといった拡張機能は、そちらの側で動く。最初にコンテナへつないだとき、この VS Code Server が手元からコンテナに送り込まれる。 この分け方のおかげで、拡張機能はコンテナに入っている処理系やコマンドをそのまま使える。Python の拡張機能はコンテナの中の Python を見に行き、ターミナルを開けばコンテナの中のシェルが立ち上がる。手元のパソコンに Python が入っていなくても、補完もデバッグも普段どおりに動く。ただし、配色のテーマやキー割り当てのように画面にしか関わらない拡張機能は、手元の側で動く。 作業中のファイルそのものは、標準では手元のフォルダーがコンテナの中に「バインドマウント」という形で見えるようになっている。コンテナの中では /workspaces/フォルダー名 という場所に現れ、そこで編集した内容は手元のフォルダーにそのまま反映される。つまり、コードは手元に残り、それを動かす道具だけがコンテナに入る。コンテナを消してもソースコードは消えない、というのがこの仕組みの安心できるところだと思う。 用意するのはDockerと拡張機能が1つずつ コンテナを動かす土台として、Docker が必要になる。Windows と macOS では Docker Desktop を入れるのがいちばん手早く、Windows では WSL2 を使う設定にしておくのが基本だ。Linux なら Docker Engine をそのまま使える。Docker Desktop は個人での利用や学習、従業員250人未満かつ年間売上1,000万ドル未満の小規模な事業であれば無料で使える。それを超える会社で使う場合は有料の契約が必要になるので、職場のパソコンで試すときは一度確かめておきたい。Docker Desktop の代わりに Podman や Rancher Desktop を土台にする方法もある。 ...

Python を書き始めてしばらくすると、どこかで「仮想環境を作りましょう」という一文に出会う。入門書の多くは標準の venv を使う手順を載せていて、ここ数年の解説記事やプロジェクトの README には uv という名前もよく出てくる。どちらも「仮想環境を作る」ための道具として紹介されるので、最初のうちは何が違うのか分かりにくい。 私自身、両方を使い分けるようになってから気づいたのは、この二つは同じ仕事を奪い合っているのではなく、受け持つ範囲の広さが違うということだった。venv は「部品を入れる箱」を作るところまでを担当し、uv は箱を作ったうえで「何をどの版で入れたか」の記録や、Python 本体の用意まで引き受ける。この記事では、そもそも仮想環境が何を解決しているのかを確かめたうえで、venv と uv の作り方、記録の残し方、速さの理由を順に見ていき、最初の1本をどちらで作るかの目安を示したい。 仮想環境は、プロジェクトごとに部品の置き場を分ける仕組み エディターの下端には、そのファイルを動かしている Python の版が表示される。仮想環境を作ると、ここで選ぶ相手が増えるPhoto: MikeRun / CC BY-SA 4.0 Python で何かを作るときは、表計算のデータを扱う部品やグラフを描く部品のように、ほかの人が公開しているパッケージを取り込んで使うことが多い。これらは pip install で入れるのが基本だが、何も考えずに入れると、パソコンに入っている Python 本体の置き場にすべてが積み上がっていく。 困るのは、プロジェクトが二つ、三つと増えたときだ。古いプロジェクトでは部品の版1を前提に書いたのに、新しいプロジェクトのために版2へ上げた途端、古いほうが動かなくなる。版を戻せば今度は新しいほうが壊れる。どちらのプロジェクトがどの部品を必要としていたのかも、時間がたつと分からなくなる。 仮想環境は、この置き場をプロジェクトごとに分ける仕組みだ。プロジェクトのフォルダーの中に .venv という専用の置き場を作り、そこに Python の実行ファイルへの参照と、部品を入れる site-packages というフォルダーを用意する。その環境を使っているあいだは、pip install した部品が .venv の中だけに入り、ほかのプロジェクトには影響しない。不要になったら、.venv のフォルダーを丸ごと消せば元どおりになる。 要するに、仮想環境の本体はただのフォルダーで、特別な仮想マシンのようなものではない。この点を押さえておくと、venv と uv の違いも見通しやすくなる。 venvは標準の道具で、箱を作るところまでを担当する venv は Python 3.3 から標準で付いてくる仕組みで、追加で何かを入れなくても使える。作り方は、プロジェクトのフォルダーで次の1行を実行するだけだ。 python -m venv .venv これで .venv フォルダーができる。中には環境の設定を書いた pyvenv.cfg と、実行ファイルを置く場所(Windows では Scripts、macOS と Linux では bin)、部品を入れる site-packages が並ぶ。Python 3.4 以降は、作った時点で pip も環境の中に入っている。 ...