Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[question] g compared to goenv #3

Closed
omares opened this issue Apr 30, 2018 · 2 comments
Closed

[question] g compared to goenv #3

omares opened this issue Apr 30, 2018 · 2 comments
Labels
question Further information is requested

Comments

@omares
Copy link

omares commented Apr 30, 2018

Hey there,

you are listing various g alternatives but you are missing goenv. Do you mind adding it?

Best

@stefanmaric
Copy link
Owner

Hey @omares, I actually didn't know about it.

It looked to me like a good alternative and gave it a try. I'm going to add the key points to the readme but going to leave an extended comparison here for future reference.

So the approaches are different, g relies on fixed values for GOPATH, GOROOT and PATH and simply copies over the files for the activated version into the fixed GOROOT dir, g always uses a "global" version (not actually, but more on that later).

goenv works by injecting several dirs into your PATH, shim files named as the various go commands are run instead of the real ones and those simply read a file (or env var) that holds the active go version and look for it inside the versions folder to run it, passing whatever arguments they got.

What I don't like about goenv:

  • You have to upgrade goenv before getting a new version of go since it keeps a hardcoded list of versions.
  • Adds a lot to your env and PATH.
  • Onboarding experience is not very smooth, besides manually cloning the repo (in case you don't have Mac or don't use homebrew) and editing init files, it was not clear to me that after installing a go version I had to activate it with goenv global <version>.
  • In general I feel it too complicated to me, less than others like gvm but still complicated.

One thing you might miss from goenv is go versions in a project basis, but it can be mocked using g. For example, in bash, if you want to have this functionality, you can simply add this alias to your init file:

go() {
  if [[ -f ".go-version" ]]; then
    local version=$(cat .go-version)
    if g run "$version" version > /dev/null; then
      g run "$version" "$@"
    else
      g install "$version" && g run "$version" "$@"
    fi
  else
    command go "$@"
  fi
}

g manages a global go version only, but g run allows you to run versions in a command basis.

Right now, g run simply fails if you indicate a version that's not installed yet, thus the check on that snippet. I might consider to change its behavior to simply install the requested version if not already.

I might also consider having the install script to optionally setup this alias in known shells.

Overall, I think g is way simpler than goenv and provides almost the same feature set with an easier kickoff, which is the main reason for g to exist.

@stefanmaric
Copy link
Owner

Going to close this issue but feel free to continue the thread.

@stefanmaric stefanmaric added the question Further information is requested label Feb 27, 2019
stefanmaric added a commit that referenced this issue Jul 8, 2019
- Add support for listing and installing unstable versions
- Prevent bugs in config files without final newline
- Ensure the modified PATH is exported on bash and zsh
- Prevent multiple selection of the same shell in g-install
- Improve the --quiet modifier
- Normalize messages styles and wording
- Support double-dash to signal end-of-params
- Tweak README file
- Offer to install latest go version after installing g
- Install requested version when `g run` cannot find it. See #3
- Warn about installing on a non-default path. See #5
- Add goenv to the alternatives list on README
- Add instructions for removal on README
- Make the detection of previously installed g stricter
stefanmaric added a commit that referenced this issue Jul 8, 2019
- Add support for listing and installing unstable versions
- Prevent bugs in config files without final newline
- Ensure the modified PATH is exported on bash and zsh
- Prevent multiple selection of the same shell in g-install
- Improve the --quiet modifier
- Normalize messages styles and wording
- Support double-dash to signal end-of-params
- Tweak README file
- Offer to install latest go version after installing g
- Install requested version when `g run` cannot find it. See #3
- Warn about installing on a non-default path. See #5
- Add goenv to the alternatives list on README
- Add instructions for removal on README
- Make the detection of previously installed g stricter
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
question Further information is requested
Projects
None yet
Development

No branches or pull requests

2 participants