Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Closed
disruptek opened this issue Nov 5, 2019 · 4 comments
Closed

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

disruptek opened this issue Nov 5, 2019 · 4 comments

Comments

@disruptek
Copy link
Contributor

disruptek commented Nov 5, 2019

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

Edit. title was misleading

@disruptek disruptek changed the title The --nimblePath is additive and there is no work-around The --nimblePath is additive; need a pain-free workaround Nov 5, 2019
@kaushalmodi
Copy link
Contributor

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
Copy link
Contributor

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
Copy link
Contributor

dom96 commented Nov 5, 2019

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
Copy link
Contributor Author

I'm building lockfiles.

disruptek added a commit to disruptek/Nim that referenced this issue Nov 6, 2019
@Araq Araq closed this as completed in 738c957 Nov 6, 2019
kiyolee pushed a commit to kiyolee/nim that referenced this issue Nov 7, 2019
narimiran pushed a commit to narimiran/Nim that referenced this issue Nov 20, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants