nimble seems to default to using its own nim binaries

[derek-v-s]

My experience was:

1. nimble install nimlangserver at which point, unknown to me, nimble created its own version of nim via ~/.nimble/pkgs2/nim-2.0.8-46333e8f4bda41dd6d3852a3f5fa4975b96b66a2/
2. nimble install nimlsp at which point, unknown to me, nimble used that version of nim to build nimlsp
3. Zed editor informed me of the mismatch between my system version (2.2.4) and nimlsp's/nimble's

So if it hadn't been for Zed's popup I would be unaware of this.

While flags like --useSystemNim, --nim:path, --disableNimBinaries exist, they require knowing about this functionality, and I think most users probably expect that nimble will default to the system version of nim (or what is set in a nimble file). Do reasons exist for keeping the behavior the way it is, regardless of unexpected results for the user?

[Araq]

Afaik it's caused by nimlangserver using the lockfile feature. And for a reproducible build using a specific Nim version makes sense. That said I think nimlangserver shouldn't use a lockfile.

[derek-v-s]

If one project's lockfile is affecting the build of a different project, that seems like a serious problem. Is anyone looking into this?

[jmgomez]

The nim version used is decided by the solver. Surely it can be patched later and to the best of my knowledge it is.
But yes, global packages pollutes the environment for sure. But I think (and I never looked at it) that the issue of the mismatch is in the nimlsp side of things and this is a key difference with nimlangserver: it uses your project's specified nim version for suggestions rather than the one which is compiled with.