開発環境の構築は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山に登る人が後を絶たない気がする）
環境をインストールしまくってディスク圧迫したときも、復元可能なテキスト情報だけを残して、さくっとバイナリクリアしてディスクを空けれるのもすごい魅力。やろうと思ったときに、掃除で時間を取られるのは本当に萎える。

このあと、自分で試みた構築手順や事例などを挙げていく。
・・・が続きはボチボチ書いていく。

スクラップって非公開にできるのかな・・・推敲してから公開したんだけど・・・

waterz1815 4ヶ月前に更新

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)

!

ブラウザからのダウンロードは速いけど、コマンドライン経由でDLするとなんか遅いです・・・

# curl経由でのNixOSのダウンロード
curl https://github.com/nix-community/NixOS-WSL/releases/download/2311.5.3/nixos-wsl.tar.gz -o ~/Downloads/nixos-wsl.tar.gz

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

waterz1815 4ヶ月前に更新

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-cliの最新は、6.3.10 であるが、
そのバージョンだと下記事象になるため、回避のため低いバージョンを指定している。

エラーが出てExpo startが失敗する
Error: Cannot find module '@expo/config/paths'

https://qiita.com/mikanbaco/items/bf7a190e8fbc053ca1cf

!

エコシステム自体のバージョン管理がシビアな場合は、
（expoみたいにガンガン新しいバージョンに代わって、追従が要求される場合は）
上記のようにdevbox側で管理するのがいいと思う。

ただし頻繁にバージョンが上がると、インストール時のキャッシュが適用されないので
バージョン指定しないと、毎回DLが発生する場合もある。

手軽さを重視するなら、下記のように直接インスト―ルして

nix profile install nixpkgs#nodePackages.npm
nix profile install nixpkgs#nodePackages.expo-cli

アプリごとにバージョン指定が必要な場合のみdevboxでインストールする方法もある。

# アプリを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

!

npx expo start　コマンドのデフォルトパラメータは「--lan」であり、

    -m, --host <string>             Dev server hosting type. Default: lan
                                    lan: Use the local network
                                    tunnel: Use any network by tunnel through ngrok
                                    localhost: Connect to the dev server over localhost
    --tunnel                        Same as --host tunnel
    --lan                           Same as --host lan
    --localhost                     Same as --host localhost

上記から、デフォルトでLAN外からの接続は許容しない。

しかもwsl2での起動の場合は、wsl側にクローズドなIPが動的に割り当てられ、
またポート番号も隠蔽された値であるため、
そもそもwslからではQRコードを読み込んでも、リクエスト自体がそもそも到達しない。

また仮にファイアウォール解除や動的IPへのポートフォワードといった回避を行っても
expo内で外部からの接続をはじくため、上記のトンネル指定がないとQRコード連携が行えない。

逆にトンネル指定を行うと、ngrokの仕組みで外部サーバーからトンネリングされて接続されるので
ファイアウォールやポートフォワードを気にすることなく利用できる。

ただし、社内から使用する場合はプロキシを経由するケースが多いため、
プロキシ対策は下記記事が参考になると思います。

https://note.com/mooya/n/ne49d6ecb2d37

wslでの利用は、トンネルモードを利用することであっさり片付いたが、
そこに至るまでに多くの方があの手この手で回避していて、非常にはまりどころだと思います。

トンネル利用派

platform-tools派

docker利用派

エミュレータ派

ブリッジモード派