exec-env improvements

[scop]

See individual commit messages for details on each change.

[missingcharacter]

Checking if GOROOT and GOPATH should be more than enough, there is no need to add unset or add 2 environment variables (ASDF_GOLANG_DISABLE_GOROOT, ASDF_GOLANG_DISABLE_GOPATH

[missingcharacter]

I just finished reading asdf-community/asdf-direnv#149, I think GOPATH should not be changed if it was already set since GOPATH is normally a developer's workspace.

but you are right about unsetting/setting GOROOT depending on the switch between versions

[scop]

I agree changing is more crucial for GOROOT if it's set.

For GOPATH, one approach would be to change if the already set value looks like something asdf-golang has set it to earlier, otherwise leave alone.

Anyway, I can revise this PR once I know what behavior the maintainers here prefer.

Personally, I would drop touching both GOROOT and GOPATH altogether, no matter if set or not. That'd be a backwards incompatible change though -- therefore the ASDF_GOLANG_DISABLE_* variables, to make the breaking change opt-in.

[kennyp]

Thanks for the PR @scop! I've got the next two weeks off, so I'll spend some time digging into this one.

[scop]

Rebased to resolve conflicts, cleaned up indentation some.

[scop]

Anything I can do to help with this?

[darthShadow]

Hi,

Is there anything that can be done to get this merged? Is there anything missing or broken here, apart from the conflicts due to the age of the PR?

[darthShadow]

Just to clarify my reason for bumping this, my custom GOPATH is always overwritten right now by the GOPATH in the exec-env script.

This seems to be because GOPATH is never passed through by asdf when calling the exec-env script so it falls through to the unset condition.

References:

• https://asdf-vm.com/plugins/create.html#bin-exec-env
• https://github.com/asdf-vm/asdf/blob/master/internal/cli/cli.go#L568-L580

Prepare the environment before executing the shims for the binaries for the tool.

**Environment Variables available to script**

- `ASDF_INSTALL_TYPE`: `version` or `ref`
- `ASDF_INSTALL_VERSION`:
  - Full version number if `ASDF_INSTALL_TYPE=version`.
  - Git ref (tag/commit/branch) if `ASDF_INSTALL_TYPE=ref`.
- `ASDF_INSTALL_PATH`: The path to where the tool _has been_, or _should be_ installed.

[missingcharacter]

@darthShadow, was this happening with asdf versions of 0.15.0?

I ask because asdf version 0.16.0 and above overlooked a bunch of behaviors/features we "got for free" by using bash, and now, with the rewrite in go, asdf needs to acknowledge and finally communicate if they'll implement them or ask maintainers of plugins to "deal with it".

[darthShadow]

Can't really say for sure.

Theoretically, I would say yes, because bash may have been passing through the variables unless they were cleared intentionally, but golang requires them to be explicitly declared for any shell-command executions.

However, I recently moved from Goland to Cursor, and it requires a couple of tools to be installed separately. That switch led me to this issue since the installs were going to a different path than expected and required a reinstall on every restart of Cursor.

[missingcharacter]

@darthShadow you can still downgrade to asdf version 0.15.0 and below if you'd like to confirm, this can help @asdf-community/asdf-golang

[darthShadow]

Yep, can confirm v0.15 is passing through all environment variables and v0.16 is only passing the specified subset.

[missingcharacter]

@darthShadow I believe your issue will be fixed when asdf-vm/asdf#1899 is merged. There may be other places where asdf needs to pass variables to go's syscall.Exec and like I said before:

asdf needs to acknowledge and finally communicate if they'll implement them or ask maintainers of plugins to "deal with it".

[darthShadow]

I don't think that specific PR will help? That seems to be only for plugin updates and doesn't pass through GOPATH.

I would guess this needs a separate PR upstream that either allows all environment variables to pass through as before or allows a plugin to specify which ones it is interested in. The second option is probably cleaner but will require changes in all plugins relying on the first option.

[darthShadow]

Upstream bug report: asdf-vm/asdf#1924

[missingcharacter]

Thanks @darthShadow

[scop]

JFYI, I do not intend to work further on this or resolve conflicts etc, as I'm no longer using asdf (have switched to mise). I suggest someone who does take this over.

[missingcharacter]

@scop thanks for sharing mise I switched too 😄