複数プロジェクトの依存パッケージをまとめて管理するnimの新しいツールatlasを試す。

devbox init
devbox generate direnv
devbox add nim-atlas

devboxを初期化、atlasをインストールする(インストール時はatlasじゃなくnim-atlasであることに注意)。
devbox generate direnvは任意。

atlas init --deps:_deps

atlasのワークスペースを現在のディレクトリで開始。
--deps:_depsフラグでワークスペースの依存パッケージが_deps/配下にインストールされるようにする。

atlas env 任意のバージョンでnimのインストールができるが、clang由来のエラーが出て安定してなさそうだったのでいつも通りnim, nimbleはdevboxでインストール。

devbox add nim@2.0.4 nimble@0.14.2

mkdir myproject
cd myproject

atlas initしたディレクトリの直下にプロジェクトを作成。nimble initなどでmyproject.nimbleを作成する。

パッケージの追加

ここからプロジェクトで使用するパッケージをインストールしていくが、やりたいことによってコマンドが異なることに注意。
追記: プロジェクトルートでテストやコンパイルをする場合、同じくプロジェクトルートにnim.cfgがないと追加したパッケージが実行時に認識されないので以下のいずれかのコマンドを--cfgHereフラグ付きでプロジェクトルートで実行すること。

1. コード上で依存するパッケージをインストールする場合

atlas use パッケージ名/URL

nimbleファイルに記述がなければ、自動でrequires パッケージを追記してくれる。

2. 開発環境に依存するパッケージをインストールする場合

atlas clone パッケージ名/URL

LSPなどはこちら。
こちらはnimbleファイルへの追記はされない。

3. nimbleファイルに記述されているrequires XXXをまとめてインストールする場合

atlas install プロジェクト名.nimble

いずれの場合にもプロジェクト名/src/nim.cfgにライブラリやコマンドのPATHが追記されるため、importやコマンドの使用ができるようになっている(はず)。

langserverのexecutableがない、、手動でbuildする？

おそらくグローバルにnimbleをインストールしていれば_deps配下のlangserverでexcutableをbuildできたはずだが、今回はnimbleもローカルでインストールしているので難しそうだった。

devbox add nimlangserver

なのでlangserverもdevboxでインストールした。

パッケージの追加に追記した通り、--cfgHereでプロジェクトルートにnim.cfgが生成されればプロジェクトルートでプロジェクトをコンパイルできるが、nimble経由でパッケージをインストールしていないため、nimbleコマンドとnimbleファイルで定義したtaskは使えない。taskについては、代わりにプロジェクトルートにconfig.nimsを定義して同じtaskを定義すれば問題ない。

既存のプロジェクトもこのワークスペースに移動した。atlas install XX.nimble --cfgHereさえ実行すればセットアップが完了するので移行もかんたん。以前はプロジェクト毎にやっていたdevbox init→nimble install ..を省けるのでストレスなく新しいプロジェクトを始められる。また、今回は1つのワークスペースにつき1バージョンのNimをインストールしたがnim本体もatlasでの管理にすればプロジェクト毎にバージョンを変更できる(たぶん)

同一ワークスペース内のプロジェクト間の依存関係

あるワークスペースに、いずれもnimbleでインストール可能なパッケージ

• プロジェクトA
• プロジェクトB
• プロジェクトC
• プロジェクトD

があり、AがB, C, Dと、他人のプロジェクトFに依存している場合を考える。なお依存パッケージは_deps/以下にインストールされる。
試しに、すべての依存パッケージをプロジェクトA.nimbleに記述してatlas install プロジェクトA.nimbleを実行すると、atlasはワークスペース内にB, C, Dがあることを確認してFだけ_deps/にインストールする。また、生成されるnim.cfgにもB, C, Dのローカルのパスが記述される。
依存関係の解決の優先度は、ローカルのパッケージ→オンライン。以下の操作を試す:

1. プロジェクトBをワークスペースから除外したあともう一度atlas install プロジェクトA.nimbleを実行するとBが_deps/にインストールされる。nim.cfgのパスも_deps/以下に変更される。
2. その後、プロジェクトBをワークスペースに追加してatlas install ...とするとワークスペース直下と_deps/以下のどちらにもプロジェクトBが存在するが、優先度に従いnim.cfg内のプロジェクトBのパスがローカルのパスに変更される。

あと、nim.cfg内に勝手に--noNimblePathが書かれるけどパッケージの使用者がatlasを使ってない場合邪魔になってしまうので.gitignoreへの追加を推奨