The --nimblePath is additive; need a pain-free workaround

[disruptek]

Per title, --nimblePath is an all-or-nothing feature that precludes the specification of an authoritative alternative source of imports.

Edit. title was misleading

[kaushalmodi]

I've been recently having issues with this too..

• --nimblePath adds to the default nimble paths. So if a user has packages in ~/.nimble, they will always be included in the nim path.
• --noNimblePath remove all nimble paths.

My use case is there I want nim to look at only a sandboxed/stable nimble pkg collection in one directory and exclude my personal ~/.nimble (because when I deploy the code in my team, I want to assure that I test my code without the pkgs in my ~/.nimble affecting the outcome).

We essentially need a --nimblePathOverride.

---

PS: Setting the env var NIMBLE_DIR also doesn't help with this situation.

[genotrance]

The local deps mode will start to address this exact issue. RFC here.

Right now, we are only covering Nimble changes to support this mode but step two is to address how this will be communicated to Nim. There may be code changes required in Nim as well but the current idea is to use nim.cfg to communicate --noNimblePath + multiple --path calls. We will refine this idea once step 1 is done.

This also ties into this issue where Nimble nuances needn't be known to Nim and ideally the nim.cfg method can handle even the user deps mode scenario. All TBD.

[dom96]

I'm really curious about the use cases for this feature...

(because when I deploy the code in my team, I want to assure that I test my code without the pkgs in my ~/.nimble affecting the outcome).

You can already get pretty far in assuring this by just using nimble to compile your project. Of course, without lock files it's not 100% reliable, but lock files is what we really want in the long-term to support this use case, not many project-specific nimble directories.

[disruptek]

I'm building lockfiles.