Add config to set ENVVAR to manifest

[tbnguyen1407]

Problem

Certain packages require setting envvar for a working installation (e.g. go needs to set GOROOT).

Suggestion

Allow specifying envvars to set in manifest. Sample go manifest from scoop

{
    "env_set": {
        "GOROOT": "$dir"
    }
}

[candrewlee14]

Good idea! It seems like we could add a folder called shell in the webman dir that has webman_zshrc, webman_bashrc, etc. that a user could source in their own shell config. The tricky part is Windows...

[AndrusGerman]

In the .bat file that runs the binaries if you can add the 'set' command in windows

set GO_ROOT=C:\goroot\
set OTHER_ENV=value
runcomand...

On linux it would be to edit the .bashrc and .zshrc file

@candrewlee14

[candrewlee14]

That's super clever, great idea.
Would you want to write a PR for that?
@AndrusGerman

[tbnguyen1407]

Should use setx instead of set for persistence? Otherwise the envvar is only applied for the executable and not detectable by other tools (e.g. for java, JAVA_HOME needs to be persisted so other tools can detect it).

I think a better approach is support some sort of post-install hooks where you can do those kinds of things:

• setting envvar
• modifying registry (e.g. for adding Context Menu entry)
• run some init commands
• etc

[candrewlee14]

@tbnguyen1407 You’re right, a way to permanently set an envvar would definitely be better. setx is a good option. It may not be so easy to remove from path, I’m not sure.

I’m coming around to the idea of post-install hooks, I just don’t like the idea that package maintainers could potentially write the post-install script to run anything. I wouldn’t allow obvious pull requests like that, but I can’t perfectly vet every command. Is there a way we could better secure that route but still allow it?

[jolheiser]

Instead of post-install hooks, what about post-install instructions?

[candrewlee14]

So I've got an idea, but I need a little help to think it through.

Let's say we manage webman.zsh, webman.bash, webman.fish, and webman.ps1 shell profile files that users can source. Here's a relevant link about how to make that work with Windows.

Packages can have a shell_map that has bash, zsh, fish, andpowershell objects that have lists of single line strings to add to the corresponding shell profile.
When these lines are added, we can append comments specific to the package & version, making it easy to search for and remove when uninstalling.

I think this would allow us to both set envvars and have additional scripts to add in our shell profiles, so we can set GO_ROOT and we can add a package for something like https://github.com/wfxr/forgit. It'd be nice also to add a convenience feature for an env_map of key-value pairs, which would add to those same profile scripts likely.

Would love to hear all of your thoughts. It's a tradeoff of security and convenience here. I think this convenience feature would be worth it, and would open up the door to a lot of new packages that currently can't be supported.
As we go forward, we can talk about what kind of checks we can do to automatically vet these shell scripts.

[tbnguyen1407]

I think this approach is specific to shell usage, which activates the envvars per session. A run-once way to permanently set the envvar is still required for non-shell applications like IDEs to detect the installation.