Go env (GOROOT, GOPATH, etc) on host shell pollutes the Golang inside devbox shell

[jaredhancock31]

Consider I have Go 1.20 installed on my host shell, with the requisite environment variables exported for it (e.g., GOROOT, GOPATH, etc.)

Now I have a repo with a devbox that uses Go 1.22. When I execute devbox shell all the environment variables are carried over and thus go env GOROOT will still point to the 1.20 files, which makes operations from within devbox to be messy, to say the least.

Is there a good way to make this more seamless? I'm hoping to declaratively define devbox.json files such that different projects can pin different Go versions, irrespective of what is going on in the host. I know that technically using --pure would do this, but that would require a lot more effort for various reasons. Golang is kind of the only portion of the dev shell that I need to have "isolated" from the host - all the other packages are working flawlessly :)

Is there a clever way to effectively omit certain env variables like GOROOT from the devbox shellenv without having to statically supply the entire thing? Or perhaps a standard init hook to rewire the variables upon entering the devbox?

Cheers!

[savil]

In Devbox's own devbox.json, we have a couple of lines in the init-hook for this scenario: https://github.com/jetpack-io/devbox/blob/main/devbox.json#L17-L19

Does that work for you for now?

Yeah, this would be nicer to do with a golang plugin maybe. cc @Lagoja thoughts?

[jaredhancock31]

Is there a clean way to absorb the Go env that the package inside would normally provide if there was no Go present on the host? Our devs typically want the shell as a long-lived sandbox as opposed to the one-off devbox run some-script-amd64.

I was also looking to do some additional things in the init_hook like doing go install for some less-popular packages. This way people have all the different tools they need once they start it up. But obviously the environment variables need to be in place beforehand.

[savil]

Is there a clean way to absorb the Go env that the package inside would normally provide if there was no Go present on the host?

@jaredhancock31 I think you'd have to export go env in the init-hooks. Something like:

"go env | while IFS= read -r line; do export \"$line\"; done",

does that work for you?

[jaredhancock31]

@savil I tried just now with the env and init_hooks from the devbox.json you linked first. I think it should be enough after all.

{
  "$schema": "https://raw.githubusercontent.com/jetpack-io/devbox/0.10.0/.schema/devbox.schema.json",
  "packages": [
    "go@1.20.14",
    "go-task@latest",
    "awscli2@latest",
    "kubernetes-helm@latest",
    "kubebuilder@3.12.0",
    "kubernetes-controller-tools@0.14.0",
    "mockgen@1.6.0",
    "golangci-lint@1.56.2",
  ],
  "env": {
    "GOENV": "off",
    "PATH":  "$PATH:$PWD/dist"
  },
  "shell": {
    "init_hook": [
      "unset GOROOT GOPATH GOMODCACHE GOBIN GOTOOLDIR",
    ],
    "scripts": {
      "test": [
        "echo \"Error: no test specified\" && exit 1"
      ]
    }
  }
}

from host shell, which has go 1.21 installed with GVM:

gvm use go1.21 && go env GOROOT

Now using version go1.21
<redacted>/.gvm/gos/go1.21

Then compared it to the same within devbox

devbox shell
go env GOROOT

/nix/store/xkwl1ycwwnq6b1ga5lxkqhjxlpd7f2sj-go-1.20.14/share/go