Is it possible to define environment variables, or specify a shell script to be sourced, per environment? about nave HOT 12 CLOSED

I agree, this is a good idea, feels like expected behavior. The pwd-based files should have higher priority, but it should source the files in $NAVE_DIR first.

from nave.

Wouldn't be hard to add. What is it typically set to? What goes in that path?

from nave.

But yes, you can run something in every nave env you enter by dropping a file at ~/.config/.naverc if ~/.config exists and ~/.nave does not exist, or ~/.naverc otherwise. That script will have all the various NAVE* environment variables set, and it's sourced in the shell, so you can export whatever you need to.

Lmk what you land on, and maybe we can just make $PNPM_HOME part of the default set.

from nave.

I only gave $PNPM_HOME as an example.

I am aware of .naverc, but this one is always sourced by nave, while I want a file that would be sourced specifically when entering the subshell for a particular node environment and not others. My project uses two different node versions via nave, and I want to be able to set separate $PNPM_HOMEs for each of those (for now I downgraded to pnpm v6 to avoid the problem).

I understand that code in .naverc knows (via environment) which particular node environment it is being sourced for, so it is probably possible to code this feature in .naverc, but I'm not a fan of coding anything in bash that isn't a straight sequence of commands ;)

from nave.

Weird, I just got the email about your June 5 message and most recent one at the same time, and now I don't see your most recent message here. Maybe you deleted it? Or GitHub or gmail got hungry? Anyway, sorry for the slow turnaround.

I'm not a fan of coding anything in bash that isn't a straight sequence of commands ;)

Hahah, we're fans of different things ;)

So yes, if you want a way to source some bash file that's included in a given project, that'd probably work, but the real blocker here is that you don't want to have it sourced for all projects, or require that the user put anything in their home directory. That makes sense.

Bonus points if the filename had to match the nave env somehow, so if you did nave use blah 16, it'd look for:

• .naverc_foo
• .naverc_16
• .naverc_16.19
• .naverc_16.19.0
• .naverc_foo-16
• .naverc_foo-16.19
• .naverc_foo-16.19.0

Then you could set a config for any of "this named env", "any env of a version v16, v16.19, v16.19.0", or "this named env at this version".

Right now, the local .naverc mimics the behavior of .nvmrc, in that it's just arguments to nave use (for use with nave auto). So the only weird part of this is that it would look related. Maybe call it .nave_profile{_...} to avoid that confusion? Plus, then .nave_profile in the local dir could just be the "run for any nave shell" variant.

from nave.

Won't be too hard to do, actually, just needs to be done in the shell env file that nave writes out. Then you can put whatever in whichever local config file makes sense for your project. I'll have something put together soon.

from nave.

I deleted my most recent comment. I took a different approach with my current problem, but I'm still using nave, and I still believe that the feature might come in handy.

I realized that since I already isolate nave itself into a (gitignored) subdirectory of the project root by setting $NAVE_DIR, I can just create $NAVE_DIR/.naverc and it gets sourced just fine, and in there I can source or define whatever I want, using $NAVE_DIR and $NAVE to construct the path and to make decisions.

from nave.

Ah, perfect. I'll leave this open though, I also think it'd be handy.

from nave.

Landed on v3.4.0

from nave.

Thank you!

I just checked this new feature, and unfortunately there's still one bit missing. The profiles are only find-upped from $PWD, but not looked for in any location that depends only on $NAVE_DIR and the which-environment information - and that is what I need. In my specific use case, those per-environment profiles are not supposed to be managed, or even known about, by users; they are supposed to be like C:\WINDOWS\System32 to them ;)

I see that $NAVE_DIR/../.naverc is still sourced from .zshenv, but only by that verbatim name. If the suffixing logic were employed there too, that would completely solve the problem for me. Actually I switched to named environments and I am always referring to them by name (and I see no reason to ever go back to version numbers), so $NAVENAME will be available in $NAVE_DIR/../.naverc and I can work with that. However I think it would be nice to have built-in per-environment selection there too, one that would handle fuzzy semver in a way consistent with how .nave_profile_*s are found.

from nave.

Just FYI, there's a sad plot twist: the original motivating case of pnpm turned out to be a dud anyway. In pnpm v7 they removed all possibilities of overriding the default configuration search paths. This whole issue was about making it possible to pass different envs to pnpm from different node environments, but pnpm just ignores the one crucial variable that would make the desired separation possible: NPM_CONFIG_USERCONFIG.

from nave.

What a bummer. Well, it motivated some good ideas in this tool, that's cool anyway 😅

from nave.