お試しの開発環境構築は、wsl+NixOS+devbox がすっごく快適
開発環境の構築はwsl+NixOS+devbox がいい感じ・・・という話。
devboxで単純さとわかりやすさを!
wslで手軽さを!
NixOSで安定性と伸びしろを!
・・・みたいな感じです。
この組み合わせのいいところを挙げていく。
- 環境構築が楽にできると、思ったよりも学習速度が速くなる
- 学習コストが低く一本槍で前に進めるので突破力が得られる。折れない心!
- 環境構築に関連するストレスがかなり減る。心の安寧は正義
- その結果、作業が楽しくなったらいいね!
学習速度が速くなる
- 開発環境を簡単に作れる。これがサクッとできると「試しにやってみよう」の速度が激上がって、結果学びの速度があがり、その範囲も広がる。
- コマンド一発で開発環境が作れる。すげー気持ち良くて取り組むテンションが上がる。初学者が取り組んだら環境作るのに数日かかって、心が折れて終わる場合もあるのに・・・
# 例:nix develop コマンドが使えるようになったら、 # 「開発環境のテンプレート取得」というnixの機能を使って # コマンド一発でrails開発環境が作れる nix develop 'github:the-nix-way/nix-flake-dev-environments?dir=ruby-on-rails'
色々覚えなくていい
- 余分なことを覚えたくない人は、devboxの基本的な仕組みだけ覚えておけば「直観的になんとかなる」ので、「エコシステム自体への学習コスト」もかなり回避できる。
# 例:devbox コマンドは4つくらい覚えておけば、なんとかなる devbox init devbox search rails # rails環境を作りたい場合、とりあえずキーワード入れてみる > * rubyPackages.rails # 候補が出てくる devbox add rubyPackages.rails # パッケージ要求 devbox shell # 要求したパッケージがインストールされた状態になる
- 必要なパッケージが全部わからなくても、わかってるモジュールをとりあえず入れて、あとはTry&Errorで動かして都度追加していって、考えずに手探りでそれっぽいところまでたどり着くやり方もある。機械的にこうやっとけばなんとかなる・・・というがあると、めんどくなった時の突破力が出てくるので、結果的に心が折れにくくなると思う。
# 例:必要なモジュール名が事前にわかっているときは、 # 必要そうなモジュール名をひたすら羅列して追加する。 devbox add nodejs yarn electron # 開発環境でなにがしかのモジュール不足エラーがでたら、 # その都度モジュール追加をTry&Errorで繰り返し追加するなど、 # 機械的な手順で乗り切り、それっぽく動くところまで突破を図る devbox add nodePackages.npm
試行錯誤時の繰り返しのストレスが激減
- 試行錯誤中は、入れたモジュール同士のバージョンが合わなかったり、余計なものを入れてしまったせいで動かなくなった・・というのはありがち。devbox なら環境が独立してるので、新しいディレクトリでコマンドを打ち直せばOK。一度インストールしたモジュールはバイナリキャッシュされてるので、二度目以降はちょっパヤで再構築できる。繰り返しを強いられる場合でも苦を感じにくくなるはず。
- 試しに作った環境は、独立しているので終了すれば他に影響を与えない。グローバルな環境へのインストールでは後々発生するであろうポート番号やライブラリのバージョン競合を気にしなくていいのはすごく快適。
ストレスが減ると、作業が楽しい
- せっかくうまくいく環境が作れても、そのあとの何かの作業で壊れてしまうのは悲しい。Nixで環境構築すれば、環境をロールバックできるので何がまずかったのかを詰めやすく、アグレッシブに攻められる。
- 壊れた時の「またこの作業を繰り返すのか・・・」という虚無感を回避できるのは、それだけですごい励みになる。(これがつらくて、Nix山に登る人が後を絶たない気がする)
- 環境をインストールしまくってディスク圧迫したときも、復元可能なテキスト情報だけを残して、さくっとバイナリクリアしてディスクを空けれるのもすごい魅力。やろうと思ったときに、掃除で時間を取られるのは本当に萎える。
このあと、自分で試みた構築手順や事例などを挙げていく。
・・・が続きはボチボチ書いていく。
スクラップって非公開にできるのかな・・・推敲してから公開したんだけど・・・
wslにNixOSを入れる
devboxは、どのディストリビューションでも入るので、既存のubuntuにでも入れておけばいい。
いいんだけど、devbox自体が調子悪くなったり、devbox自体のバージョンアップで意図しない動作になったときにすぐに戻せるようにしたいので、NixOSを用意して、そこにdevboxを入れたい。
経験的にも、NixOSで動かした方が円滑にfetchが効いて動作が速い気がする。
wslの状況を確認する
PowerShell、WindowsTerminalなどから、下記のコマンドを実行し、wslの状況を確認する。
(Dosプロンプトでもいいけど、一部PowerShell用の表記で例を書いているので、そちらに合わせるといいかも)
# 状況把握
wsl --help # wslのコマンド説明
wsl -l # VMインスタンスの一覧
wsl -v # wslのバージョン情報
wslの状況はなかなかカオスなので、初めて使う人はハマりがちかもしれない。
上記のコマンド自体が動かない人は、別途記事を確認のこと。
自分が確認した環境は「WSL バージョン: 1.2.5.0」だったので、
それより低い人はアップデートした方が確実かも。
# wslのアップデート
wsl --update
想定する環境としては、
Windows10 以降で、最新のWindows Updateは適用済み
ディスク空き容量が2G以上のイメージです。
NixOSのダウンロード
WSL用にカスタムされたものを使用します。
ブラウザから
をダウンロードする(サイズ:404M)
DownloadsフォルダにファイルがDLされたとして、
(C:\Users%userprofile%\Downloads)
ルートディレクトリ直下の「/NixOS」にVMのディスクイメージを展開します。
WSL側の使用ディスクサイズは、500M程度です。
# NixOSのインストール
cd ~/Downloads
wsl --import NixOS /NixOS/ nixos-wsl.tar.gz --version 2
NixOSの起動
# NixOSの起動
wsl -d NixOS
wslが起動して、下記のウェルカムメッセージが表示された後、
nixos@で始まるコンソールが入力可能になったら成功です
❄️ Enjoy NixOS-WSL! ❄️
NixOSの設定ファイルの変更
Flakes(NixOSの新しい環境設定コマンド)を有効にします。
sudo sed -i -e "19i # Enable Flakes" /etc/nixos/configuration.nix
sudo sed -i -e "20i nix.package = pkgs.nixFlakes;" /etc/nixos/configuration.nix
sudo sed -i -e "21i nix.extraOptions = ''experimental-features = nix-command flakes'';" /etc/nixos/configuration.nix
sudo nix-channel --add https://nixos.org/channels/nixos-23.11 nixos
sudo nix-channel --update
sudo nixos-rebuild switch
実行完了まで少し待ちます。(私の環境では2分程度)
コンソールが入力可能になったら成功です。
以下で、wslから抜けて powerShell側に戻ります。
exit
NixOSはうごきっぱなので、以下で停止します。
# NixOSの停止
wsl --terminate NixOS
wslの操作で主に使用するコマンドは以下です。
# NixOSの起動
wsl -d NixOS
# NixOSの停止
wsl --terminate NixOS
# NixOSをデフォルトVMに設定
wsl --set-default NixOS
# デフォルトVM(NixOS)を起動
wsl
# すべてのVMを停止
wsl --shutdown
# NixOSの削除
wsl --unregister NixOS
以上で、NixOSの起動から停止までをざっと確認しました。
古いバージョン(22.05)でのNixOSインストールメモ
NixOSでdevboxを使わない場合は、22.05も有力な選択肢です。(最初の設定なしに、flakesコマンドが使用できる)
ブラウザから
をダウンロードする(サイズ:324M)# NixOSのインストール
cd ~/Downloads
wsl --import NixOS /NixOS/ nixos-wsl-installer.tar.gz --version 2
Unpacking root file system...
307MiB 0:00:21 [14.4MiB/s] [========================================================================>] 100%
Activating nix configuration...
・・・
Starting systemd...
$
# パッケージ管理に必要なアプリをインストール
nix profile install nixpkgs#git
# Nix22.05 以下でdevboxを使う時は、古いバージョン(0.1.2)を入れる
# バージョン指定ができない等、使い勝手が悪い
nix profile install nixpkgs/79b3d4bcae8c7007c9fd51c279a8a67acfa73a2a#devbox
NixOSインストール後の作業メモ
OSインストール後に行う初期設定
# パッケージ管理に必要なアプリをインストール
nix profile install nixpkgs#git
nix profile install nixpkgs#devbox
# Gitの初期設定
git config --global user.email "you@example.com" ;
git config --global user.name "Your Name" ;
思い立ってプロジェクトを作成するときの初期化設定
# homeディレクトリに移動
cd
# プロジェクトフォルダを作成
mkdir my-project
cd my-project
# 個別の開発環境設定
devbox init
devbox add nodePackages.npm nodePackages.expo-cli@6.3.1 nodejs
devbox add android-tools
devbox shell
# アプリをexpoで作成する場合の初期設定
expo init
cd my-app
# expoでwebアプリを起動する場合に設定
npx expo install react-native-web@~0.19.6 react-dom@18.2.0 @expo/webpack-config@^19.0.0
npx expo start
# Expo Go経由でQRコードからandroid実機でアプリを起動する場合に設定
npx expo install @expo/ngrok@^4.1.0
npx expo start --tunnel
# うまくいった場合のコミット
# devboxから抜ける
exit
# devboxの設定をアプリ側フォルダに移動
mv dev* ./my-app
mv .devbox ./my-app
# アプリ側フォルダに移動してコミット
cd my-app
git add -A
git commit -m myFirstCommit
wslでの利用は、トンネルモードを利用することであっさり片付いたが、
そこに至るまでに多くの方があの手この手で回避していて、非常にはまりどころだと思います。
- トンネル利用派
- platform-tools派
- docker利用派
- エミュレータ派
- ブリッジモード派