V: How to set $VROOT environment variable permanently during installation?

[medvednikov]

Good morning,

Instead of storing the path in ~/.vlang/vroot, it should be defined via $VROOT.

But I don't know how to set it without asking users to do it manually by adding the value to their ~/.zshrc.

I know that Go sets default environment variables during installation, does anyone know how that can be done?

Thanks

[pznknmtb]

rustup does the following (for path settings, but applies to any environment):
Linux: add to .profile: export PATH="$HOME/.cargo/bin:$PATH
Windows: add to registry key: HKCU\Environment\Path

[medvednikov]

Thank you @pznknmtb

I'll try that

[pznknmtb]

another note about $VROOT: if value is absent it could be possible to derive path from v binary location

[whoizit]

Windows also have PATH and env vars

[medvednikov]

That's what it's already doing

another note about $VROOT: if value is absent it could be possible to derive path from v binary location

[pznknmtb]

yes :)

[medvednikov]

Adding it to .profile doesn't work.

[pznknmtb]

you need to restart the shell or source .profile
maybe osx is different...

[medvednikov]

I tried on macos and linux with restarting of course.

[pznknmtb]

works for me on Ubuntu 18.04.2
added export VROOT=lalala to .profile as last line.
new shell. echo $VROOT works.

[medvednikov]

can you try with zsh?

[medvednikov]

Also Rust stores all its modules in ~/.cargo

V can do the same, then no VROOT is required.

[pznknmtb]

let me google that for you:
https://superuser.com/questions/187639/zsh-not-hitting-profile

[medvednikov]

See that's the problem, .profile is not a one for all solution.

[pznknmtb]

yes, might be a bash thing and require more heuristics.
I just analyzed what rustup was doing.
the source might know all the ugly details ;-)
https://github.com/rust-lang/rustup.rs

[medvednikov]

I'm now considering simply storing everything in ~/.vmodules, including builtin. No env vars required. What do you think?

[pznknmtb]

this should be OK (but I am not sure of what "everything" actually is).
the remaining issue could be using different version of v concurrently - this might be necessary or useful for certain test scenarios.

so maybe use the default ~/.vmodules and allow optional override with $VROOT for special cases.

[medvednikov]

for using different version there can be ~/.v1/modules, ~/.v2/modules etc

[JohnAZoidberg]

I think there should be at least two ways of specifying the modules directory.

One dynamic one at runtime, which could be a fixed path in the home directory or an environment variable. I think both should be used but one overrides the other one, i.e. v first searches one and tries to find missing modules in the other.

Another useful one would be relative to the compiler that built the binary. When this method is implemented I can package the compiler for my distro, build binaries and run them without needing to put something in my home or modifying the environment. For distributing built packages I can create a wrapper that calls the binary with the correct environment of the installed modules.
For other distributions it would also be useful to have a global (e.g. /usr/lib/v/ be part of the search path for globally, by a package manager, installed libraries.

[Chiiruno]

For package managers like Nix and Guix, we should consider hashed directories in the store, if possible.

[JohnAZoidberg]

@Chiiruno That's what Nix and Guix can do, my suggestions make it easy for all kinds of package managers, including Nix and Guix.

[cytown]

can you try with zsh?

zsh use .zshrc && .profile... So the best solution is use .profile, and it will satisfy all the shells.

[medvednikov]

VROOT is no longer used.