Flox-installed Go uses the global Go enviornment, is this expected?

Help
1

I am not sure if I am doing something wrong, or if this is a bug, or if this is the way Flox works.

I expected that packages installed inside a Flox environment would somehow be self-contained inside this environment. This would include creating local environment variables during the installation. However, when I installed Go, I found it uses the global Go installation’s environment.

Steps to replicate the issue:

  • Have Go installed on the system (mine is installed via Homebrew)
  • Init a Flox environment
  • Install Go
  • Test the Go environment outside the flox env
  • Activate the flox env
  • Test the Go environment and find that it is the global one. (See the shell log below: both Go installations use the same GOENV that points to /Users/christoph/Library/Application Support/go/env.)

I would have expected that the Flox-installed Go sets up its own GOENV and doesn’t use my system-global GOENV.

This results in two rather serious problems:

  1. The Flox environment is not really shareable, as the Go environment lives outside the Flox environment. This means I still have the “works on my machine” problem I want to escape by using Flox.
  2. With every change to a GOENV variable, I mess with my system-global Go installation. I would need to fix GOENV manually every time I do a flox install go.

Did I miss a step?

Is this an expected behavior?

Is this a bug with the Go Nix package?

Or, asking more generally: How can I install a Flox package and be sure that all the package’s config files and environment variables are automatically contained in the Flox environment?

Shell log:

Flox $ cd test
test $ flox init
✨ Created environment test (aarch64-darwin)

Next:
  $ flox search <package>    <- Search for a package
  $ flox install <package>   <- Install a package into an environment
  $ flox activate            <- Enter the environment

test $ flox install go
✅ 'go' installed to environment test at /Users/christoph/Temp/Flox/test
test $ which go
/opt/homebrew/bin/go
test $ go env GOENV
/Users/christoph/Library/Application Support/go/env
test $ flox activate
✅ You are now using the environment test at /Users/christoph/Temp/Flox/test.
To stop using this environment, type 'exit'

flox [test] test $ which go
/Users/christoph/Temp/Flox/test/.flox/run/aarch64-darwin.test/bin/go
flox [test] test $ go env GOENV
/Users/christoph/Library/Application Support/go/env
flox [test] test $
2

Out of curiosity, can you please try to activate your environment with

$SHELL -c "$(flox activate) && $SHELL"

I’ve had some similar activation issues and that solved it.

1 Like
3

Hej, thank you for trying out Flox!

Unfortunately, we are lacking some integration work for the Go language, to make this more seamless.

Thus, as for your questions:

Is this an expected behavior?

Currently, given that you only install the go package, and Flox does not handle custom variables for that, this behavior is the “expected” default behavior of Go.
However, we recognize the need to handle this case better.

Did I miss a step?

Today, to have an isolated GOENV, you should be able to just add a line in your hook.script field in the .flox/env/manifest.toml:

[hook]
script = """
export GOENV="$FLOX_ENV_CACHE/goenv"
"""

In the future we mean to provide this automatically or set up a hook like that with flox init.

1 Like
4

Issue created: flox init reads go.mod and suggests installation/config · Issue #1209 · flox/flox · GitHub

1 Like
5

Thank you, @etorreborre, for the suggestion. Unfortunately, it does not seem to have any effect on my end.

1 Like
6

Thank you, @ysndr, for the explanation and the tip about setting GOENV manually. This works, and it is certainly a workaround, even through I’d have to do this for all environment variables that are included in Go’s GOENV environment and have a path set at install time.

E.g, the variables

GOPATH=‘/Users/christoph/go’
GOCACHE=‘/Users/christoph/Library/Caches/go-build’
etc.

point to the same default paths that the Go installer would set outside a Flox installation.

The obvious workaround is to add a few more lines to hook.script.

1 Like
7

I think GOCACHE, is effectively just a readonly cache for downloads and build intermediates?

In that case unless you want those to be separate for each project I assume they can remain shared/the same for all projects, since the project specific packages are already locked project wide.
It would at least save you some disk space… however much that may be…

Personally i understand the desire for project specific data to be separate, but since Go already has lockfiles / sumfiles that make a project specific “environment” maybe a virtual env approach is not entirely necessary.

Please take this with the two grains of salt, that are 1) that these are my personal thoughts and 2) that I’m rather foreign to the Go ecosystem.

8

You’re right, caches would not need to be environment-specific. GOPATH, on the other hand, also sets the base dir for other settings like GOBIN. If I compile a Go binary inside a Flox environment, it would end up outside the environment, in my global $GOPATH/bin (or $GOBIN if set).