Is your feature request related to a problem? Please describe.
There are several projects that is immediately compilable on arm. It does not require using installing go using ASDF_GOLANG_OVERWRITE_ARCH. But there are projects that is not immediately compilable due to its dependency not having arm build (i.e. that depends on this), so using ASDF_GOLANG_OVERWRITE_ARCH

Problem arise if there are project of both type that needs to run on the same version

Describe the solution you'd like
Something like this should work

asdf install golang 1.17-darwin-arm64
asdf install golang 1.17-darwin-amd64

It should not change the default behaviour of asdf install golang 1.17, it still install the current arch.

Describe alternatives you've considered
What I do right now is to use different patches for different arch on the same major version. i.e.

1. go1.18.2 -> this is using darwin-arm64 (m1)
2. go1.18.1 -> this is using darwin-amd64 (running under rosetta, i guess?)

Thank you

Describe the bug

I installed asdf-golang. When I run a go command I get an error.

To Reproduce

Steps to reproduce the behavior:

1. $ asdf plugin-add golang https://github.com/kennyp/asdf-golang.git
2. $ asdf install golang 1.12.1
3. $ asdf global golang 1.12.1
4. $ go run myfile.go

Error:

go: cannot find GOROOT directory: /usr/lib/go

Expected behavior

I expected go to work without the error.

Desktop (please complete the following information):

• OS: Arch Linux
• Version asdf v0.7.0

Describe the bug
When I switch between versions the go env variables are out of sync.
This causes issues when running commands such as go install or go test

❯ go install github.com/vektra/mockery/[email protected]
# internal/goarch
compile: version "go1.19.9" does not match go tool version "go1.20.5"

❯ go test ./...
# internal/cpu
compile: version "go1.19.9" does not match go tool version "go1.20.5"

To Reproduce
Steps to reproduce the behavior:

$ asdf plugin update --all
$ asdf install golang 1.20.5
$ asdf global golang 1.20.5
$ asdf install golang 1.19.9
$ asdf local golang 1.19.9

$ asdf reshim golang
$ asdf list golang
 *1.19.9
  1.20.5
$ go version
go version go1.19.9 darwin/arm64

$ asdf list golang
 *1.19.9
  1.20.5

$ go env
GO111MODULE=""
GOARCH="arm64"
GOBIN=""
GOCACHE="$HOME/Library/Caches/go-build"
GOENV="$HOME/Library/Application Support/go/env"
GOEXE=""
GOEXPERIMENT=""
GOFLAGS=""
GOHOSTARCH="arm64"
GOHOSTOS="darwin"
GOINSECURE=""
GOMODCACHE="$HOME/.asdf/installs/golang/1.20.5/packages/pkg/mod"
GONOPROXY=""
GONOSUMDB=""
GOOS="darwin"
GOPATH="$HOME/.asdf/installs/golang/1.20.5/packages"
GOPRIVATE=""
GOPROXY="https://proxy.golang.org,direct"
GOROOT="$HOME/.asdf/installs/golang/1.19.9/go"
GOSUMDB="sum.golang.org"
GOTMPDIR=""
GOTOOLDIR="$HOME/.asdf/installs/golang/1.19.9/go/pkg/tool/darwin_arm64"
GOVCS=""
GOVERSION="go1.19.9"
GCCGO="gccgo"
AR="ar"
CC="clang"
CXX="clang++"
CGO_ENABLED="1"
GOMOD="$HOME/.../go.mod"
GOWORK=""
CGO_CFLAGS="-g -O2"
CGO_CPPFLAGS=""
CGO_CXXFLAGS="-g -O2"
CGO_FFLAGS="-g -O2"
CGO_LDFLAGS="-g -O2"
PKG_CONFIG="pkg-config"
GOGCCFLAGS="-fPIC -arch arm64 -pthread -fno-caret-diagnostics -Qunused-arguments -fmessage-length=0 -fdebug-prefix-map=/var/folders/py/yt2zkc3j2qv9cwc50ydn2_sw0000gp/T/go-build2400661110=/tmp/go-build -gno-record-gcc-switches -fno-common"

Expected behavior
For the go env variables to all be updated pointing to the current asdf version
In the go env output above the problematic variables are:

• GOMODCACHE
• GOPATH
• GOROOT
• GOTOOLDIR

Additional context

❯ asdf version
v0.11.3
❯ fish --version
fish, version 3.6.1

In my config.fish I have

source ~/.asdf/plugins/golang/set-env.fish
set -gx GOROOT (go env GOROOT)
set -gx GOPATH (go env GOPATH)

I get the expected behaviour by adding a line to this to manually update the go env

source ~/.asdf/plugins/golang/set-env.fish
go env -w GOPATH=(asdf where golang)/packages
set -gx GOROOT (go env GOROOT)
set -gx GOPATH (go env GOPATH)

Am I doing something wrong? If not could we extend the set-env functions to update the GOPATH as well as GOROOT?

Describe the solution you'd like
After installing a new version of go, run

for pkg in $(cat ~/.default-golang-pkgs) 
    go get -u $pkg
done

Additional context
asdf-node and asdf-python both support this

When you set a asdf global golang system the ASDF_INSTALL_PATH will be empty, resulting in a GOROOT' of /go which fails. Not setting the GOROOT when the version is system avoids this problem.

Simply not setting GOROOT at all in exec-env seems to do the right thing by default. When my go version is set to system it correctly grabs /usr/lib/go but when it's an asdf installed go version go env returns $asdf_install_dir/golang/$version/go, which is exactly what we want.

Describe the bug
Installed latest golang with asdf but go executable cannot be found.

~ $ asdf version
v0.8.0
~ $ asdf install golang latest
~ $ go version
go version go1.16.4 darwin/amd64
~ $ cd ~/Test/
Test $ go version
No go executable found for golang system

Expected behavior
go executable could be found from any folder.

Describe the bug
It seems like a .sha256 file only started getting provided with the downloads somewhere in 2016, which leads to this plugin being unable to install versions older than that because of a failed checksum check.

To Reproduce
Steps to reproduce the behavior:

1. asdf install golang 1.5.3
2. See error

Expected behavior
Go version 1.5.3 installs.

Screenshots

Desktop

• OS: Arch Linux 6.0.7.zen1-1 amd64
  and
• OS: Windows WSL 5.15.68.1-microsoft-standard-WSL2

Additional context
It seems like the Go team is aware of the issue, and they're planning on adding the missing checksums eventually (golang/go#45608). They are also missing from the go.dev/dl JSON list, but there are SHA1 checksums available on the plain https://go.dev/dl page.

Not sure what's the best way to go about fixing this, but, if possible to implement, maybe some kind of --skip-checksum flag or SKIP_CHECKSUM=1 env var to bypass the check would be helpful.

Describe the bug
I just installed GO version 1.14.6 with asdf. After that (and installing godoc manually, because it is no longer default in installation) the function godoc does not work anymore. I get the following message:

asdf: No preset version installed for command godoc
Please install the missing version by running one of the following:

asdf install golang 1.14.6

To Reproduce
Steps to reproduce the behavior:

1. asdf install golang 1.14.6
2. asdf global golang 1.14.6
3. go get golang.org/x/tools/cmd/godoc
4. asdf reshim golang
5. godoc help (just for testing)

Expected behavior
Execute installed godoc.

Server (please complete the following information):

• OS: Ubuntu Server 18.04.4 LTS

Describe the bug
Looks like go get is deprecated in versions 1.18.x which breaks the default packages feature of this plugin.

To Reproduce
Steps to reproduce the behavior:

1. echo 'golang.org/x/tools/gopls' >> $HOME/.default-golang-pkgs
2. asdf install golang 1.18beta2
3. See error below

Installing golang.org/x/tools/gopls go pkg... go: go.mod file not found in current directory or any parent directory.
	'go get' is no longer supported outside a module.
	To build and install a command, use 'go install' with a version,
	like 'go install example.com/cmd@latest'
	For more information, see https://golang.org/doc/go-get-install-deprecation
	or run 'go help get' or 'go help install'.
FAIL

Expected behavior
gopls to be installed.

Desktop (please complete the following information):

• OS: OSX
• Browser N/A
• Version 12.1

Additional context
asdf v0.7.8-4a3e3d6

Thank you for writing this plugin ❤️

Is your feature request related to a problem? Please describe.
Hi, are there any plans to add support for tinygo? Or should that be a separate plugin?

Describe the solution you'd like

asdf install golang 1.19.4-tinygo

Describe alternatives you've considered
Creating a separate plugin

Additional context
None

Plugin just installed.

When I run asdf list-all golang I get this error:

> asdf list-all golang 
: invalid option namelugins/golang/bin/list-all: line 2: set: pipefail

Describe the bug
I tried to install the 1.17.7 version from asdf golang plugin and got the message.

$ asdf install golang 1.17.7
Platform 'darwin' supported!
URL: https://dl.google.com/go/go1.17.7.darwin-arm64.tar.gz returned status 404

To Reproduce
Steps to reproduce the behavior:

1. Run the install command

Expected behavior
OK result and the version listed by asdf list golang command

Describe the bug

I am unable to get any of my go install binaries ($HOME/go/bin) to work with asdf-golang starting from version v1.20. I am probably doing something wrong, but it have worked perfectly with version prior to v1.20 and I am unable to figure this one out myself...

To Reproduce
Steps to reproduce the behavior:

$ asdf plugin update --all
$ asdf install golang 1.20.4
$ asdf global golang 1.20.4

$ go get golang.org/x/tools/gopls@latest
$ stat $HOME/go/bin/gopls
16777230 57318951 -rwxr-xr-x 1 $USER staff 0 25765874 "May 14 11:05:15 2023" "May 14 10:58:20 2023" "May 14 10:58:20 2023" "May 14 10:58:19 2023" 4096 52288 0 $HOME/go/bin/gopls

$ asdf reshim
$ gopls version
No preset version installed for command gopls
Please install a version by running one of the following:

$ asdf install golang 1.20.4
$ asdf global golang 1.19.3
$ asdf reshim

$ gopls version
gopls version
golang.org/x/tools/gopls v0.11.0
    golang.org/x/tools/[email protected] h1:/nvKHdTtePQmrv9XN3gIUN9MOdUrKzO/dcqgbG6x8EY=

Expected behavior

go install binaries should work with go v1.20 and reshim.

Additional context

• go version: go version go1.20.4 darwin/arm64
• asdf version: v0.11.3
• go env:

GO111MODULE=""
GOARCH="arm64"
GOBIN=""
GOCACHE="$HOME/Library/Caches/go-build"
GOENV="$HOME/Library/Application Support/go/env"
GOEXE=""
GOEXPERIMENT=""
GOFLAGS=""
GOHOSTARCH="arm64"
GOHOSTOS="darwin"
GOINSECURE=""
GOMODCACHE="$HOME/go/pkg/mod"
GONOPROXY=""
GONOSUMDB=""
GOOS="darwin"
GOPATH="$HOME/go"
GOPRIVATE=""
GOPROXY="https://proxy.golang.org,direct"
GOROOT="$HOME/.asdf/installs/golang/1.20.4/go"
GOSUMDB="sum.golang.org"
GOTMPDIR=""
GOTOOLDIR="$HOME/.asdf/installs/golang/1.20.4/go/pkg/tool/darwin_arm64"
GOVCS=""
GOVERSION="go1.20.4"
GCCGO="gccgo"
AR="ar"
CC="clang"
CXX="clang++"
CGO_ENABLED="1"
GOMOD="/dev/null"
GOWORK=""
CGO_CFLAGS="-O2 -g"
CGO_CPPFLAGS=""
CGO_CXXFLAGS="-O2 -g"
CGO_FFLAGS="-O2 -g"
CGO_LDFLAGS="-O2 -g"
PKG_CONFIG="pkg-config"
GOGCCFLAGS="-fPIC -arch arm64 -pthread -fno-caret-diagnostics -Qunused-arguments -fmessage-length=0 -fdebug-prefix-map=/var/folders/rn/qhsvm_qj7dq5brrmnflj5m5c0000gn/T/go-build773786195=/tmp/go-build -gno-record-gcc-switches -fno-common"

Hello, I've recently started using this project in combination with direnv and noticed a small improvement. What's happening is the following

1. I cd into a directory with a .envrc file
2. Any command that's executed within this directory will always trigger an direnv: unloading hook

After some research, I found that this issue was related to set-env.zsh and the use of absolute_dir_path. In fact, I found a similar issue which was resolved:
halcyon/asdf-java#144

In summary, the fix uses zsh's built in functionality to get the absolute dir path. This makes absolute_dir_path obsolete 🙂.

Describe the bug

$GOPATH and $GOROOT isn't correctly started when install, use or select a go version using asdf-golang.
Executables can't run because $GOPATH and $GOROOT isen't setted.

To Reproduce

Run this steps:

asdf install golang 1.16.4
go get -v github.com/rubenv/sql-migrate/...

sql-migrate
zsh: command not found: sql-migrate

Expected behavior

sql-migrate must be accessible.

By default, if GOBIN is not set, it is not guaranteed that the path $GOPATH/bin will be used - it is better to set it explicitly in the Environment

Describe the bug
Both $GOPATH or $GOROOT are not.

snowflake in ~
➜ go env
GO111MODULE=""
GOARCH="amd64"
GOBIN=""
GOCACHE="/Users/snowflake/Library/Caches/go-build"
GOENV="/Users/snowflake/Library/Application Support/go/env"
GOEXE=""
GOFLAGS=""
GOHOSTARCH="amd64"
GOHOSTOS="darwin"
GONOPROXY=""
GONOSUMDB=""
GOOS="darwin"
GOPATH="/Users/snowflake/.asdf/installs/golang/1.13.8/packages"
GOPRIVATE=""
GOPROXY="https://proxy.golang.org,direct"
GOROOT="/Users/snowflake/.asdf/installs/golang/1.13.8/go"
GOSUMDB="sum.golang.org"
GOTMPDIR=""
GOTOOLDIR="/Users/snowflake/.asdf/installs/golang/1.13.8/go/pkg/tool/darwin_amd64"
GCCGO="gccgo"
AR="ar"
CC="clang"
CXX="clang++"
CGO_ENABLED="1"
GOMOD=""
CGO_CFLAGS="-g -O2"
CGO_CPPFLAGS=""
CGO_CXXFLAGS="-g -O2"
CGO_FFLAGS="-g -O2"
CGO_LDFLAGS="-g -O2"
PKG_CONFIG="pkg-config"
GOGCCFLAGS="-fPIC -m64 -pthread -fno-caret-diagnostics -Qunused-arguments -fmessage-length=0 -fdebug-prefix-map=/var/folders/35/t0nqj9vd2zd735xf5d05ybzr0000gn/T/go-build082200721=/tmp/go-build -gno-record-gcc-switches -fno-common"

snowflake in ~
➜ echo $GOROOT


snowflake in ~
➜ echo $GOPATH


snowflake in ~
➜ asdf version
v0.7.6

To Reproduce
Steps to reproduce the behavior:

1. Install go using asdf-golang
2. switch to any version of the currently installed go
3. echo $GOPATH or $GOROOT
4. return emptiness :D

Expected behavior
To Have $GOPATH & $GOROOT set.

Desktop (please complete the following information):

• OS: macOS Catalina Version 10.15.3
• SHELL: zsh 5.7.1 (x86_64-apple-darwin19.0)

Additional context
Can I add a sort of Place to put my $GOPATH & $GOROOT as I want them to be inside of go folder inside of my home directory and the library append on it.
eg: installing go 1.13.8 with the following environment variable ASDF_GOLANG_CUSTOM_PATH=$HOME/go
so my $GOPATH & $GOROOT set as the following
$GOPATH=ASDF_GOLANG_PATH/1.13.8/......
$GOROOT=ASDF_GOLANG_PATH/1.13.8/......

Does asdf-golang have any interest in a compilation option in the future? I ran this command asdf install golang ref:$(asdf latest golang) expecting compilation, but received a binary installation instead.

gvm solves the bootstrapping issue by first compiling go1.4 and then compiling later versions.

I have a script that does this and it looks like gvm would work, but I am exploring the option of standardizing my tools around asdf.

Is your feature request related to a problem? Please describe.
When using a go.work file to define the source location, asdf does not pick up the tool version as it would from go.mod

Describe the solution you'd like
When present use go.work to determine the golang version using the same logic as for go.mod

Describe alternatives you've considered
The only alternative is to define the version in .go-version or .tool-versions

I just found out an issue that somehow the plugin does not respect the config files in the user home directory, but it does respect the config files in the project directory.

Not quite sure what caused the issue, (I am using the latest asdf, installed via brew). Thanks!

$ asdf --version
v0.10.2

Describe the bug
I'm trying to install go 1.11 on a mac with the m1 chip but fails with the following error:

$ asdf install golang 1.11
mkdir: /Users/wako/.asdf/downloads/golang/1.11: File exists
Platform 'darwin' supported!
URL: https://dl.google.com/go/go1.11.darwin-arm64.tar.gz returned status 404

Of course the http request gets an 404 status since 1.11 does not have a arm64 version but a amd64 one.

To Reproduce
Steps to reproduce the behavior:

1. Go to '...'
2. Click on '....'
3. Scroll down to '....'
4. See error

Expected behavior
I would like to be able to install a old version of go with this computer.

Additional context

• asdf v0.10.2
• golang plugin 4aed736

$ asdf info
OS:
Darwin akko.local 21.5.0 Darwin Kernel Version 21.5.0: Tue Apr 26 21:08:29 PDT 2022; root:xxxxxxxxx~4/RELEASE_ARM64_T8101 arm64

SHELL:
zsh 5.8.1 (x86_64-apple-darwin21.0)

ASDF VERSION:
v0.10.2

ASDF ENVIRONMENT VARIABLES:
ASDF_DIR=/opt/homebrew/opt/asdf/libexec

ASDF INSTALLED PLUGINS:
golang                       https://github.com/kennyp/asdf-golang.git master 4aed736

When running asdf list-all golang it includes results such as 1.7.freebsd-amd64 which is missing the patch number. It should be 1.7.3.freebsd-amd64

I run asdf install and I got an error.

$ asdf install golang 1.9.3
Platform 'linux' supported!
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
  0     0    0     0    0     0      0      0 --:--:-- --:--:-- --:--:--     0
curl: (60) SSL certificate problem: self signed certificate in certificate chain
More details here: https://curl.haxx.se/docs/sslcerts.html

curl failed to verify the legitimacy of the server and therefore could not
establish a secure connection to it. To learn more about this situation and
how to fix it, please visit the web page mentioned above.

asdf list-all golang doesn't print any strings.

$ asdf list-all golang
$

Describe the bug
My teammate and I are both unable to get this plugin to work out of the box. We both hit an error ASDF_DOWNLOAD_PATH: unbound variable. After setting that envvar, we got the error tar (child): /home/awichmann/Downloads/archive.tar.gz: Cannot open: No such file or directory. If you download the latest archive like wget https://golang.org/dl/go1.15.7.linux-amd64.tar.gz -O $ASDF_DOWNLOAD_PATH/archive.tar.gz it works, but I would hope downloading the archive would be carried out by this plugin

To Reproduce
Steps to reproduce the behavior:

1. asdf plugin-add golang https://github.com/kennyp/asdf-golang.git
2. asdf install golang 1.15.7

Expected behavior
I expected go 1.15.7 to be installed

Desktop (please complete the following information):

• OS: Ubuntu 18.04
• Version:

> $ asdf --version
v0.7.6-6207e42

https://github.com/kennyp/asdf-golang/blob/cc8bc47d4877beed61e10815d46669e1eaaa0bbe/bin/download#L37

Looks like 1.18.0 is only on go.dev:

asdf install golang
mkdir: /Users/ryanschneider/.asdf/downloads/golang/1.18.0: File exists
Platform 'darwin' supported!
URL: https://dl.google.com/go/go1.18.0.darwin-arm64.tar.gz returned status 404

https://go.dev/dl/go1.18.darwin-arm64.tar.gz on the other hand exists.

macOS 10.14 Mojave
go 1.11
asdf 0.5.1
asdg-golang latest

Hello, maybe I'm being really dim here, but after installing asdf and asdf-golang, and running asdf global golang 1.10 to install go 1.10 for testing purposes, I cannot figure out, nor can I actually find instructions on how to actually run golang source under go 1.10. go version still returns go1.11 darwin/amd64. I was under the impression that asdf would enabled me to switch quickly and easily between versions, but I'm obviously missing something glaringly obvious!

Hello, I found an unexpected edge case with this feature :)

The version in the go.mod file should be specified as x.y and does not allow patch revisions (like 1.14.2, see go directive docs in Go Module reference).

Trying to use a version in the form x.y.z in the go.mod produces this error:

go: errors parsing go.mod:
[...]/go.mod:3: usage: go 1.23

This creates an edge cases where you don't have a x.y Golang version installed but asdf-golang forcefully tries to load it.

In my particular case this plugin tries to load version 1.14 but I don't have it installed, as I have 1.14.2.

A viable workaround is to disable legacy file parsing, but clearly depends if it's being relied upon for other languages.

A viable solution would be to select the nearest installed version that matches the constraint (like 1.14.2 in place of 1.14).

Originally posted by @endorama in #32 (comment)

Describe the bug
When attempting to download the golang archive on FreeBSD 13 the checksum fails to verify with the following error:

verifying checksum
sha256sum: option requires an argument -- c
usage: sha256sum [-pqrtx] [-c file] [-s string] [files ...]
Authenticity of package archive can not be assured. Exiting.

This can be worked around by temporarily renaming the sha256sum tool to sha256sum.fbsd and re-running the installer.

To Reproduce
Steps to reproduce the behavior:

1. On a FreeBSD 13.1 amd64 system, attempt to asdf install golang 1.17.13
2. See error

Expected behavior
This seems to be due to an incompatibility of the between the FreeBSD 13 and Linux versions of the sha256sum tool. Temporarily renaming the sha256sum binary and re-running the command worked. Looking at the code, if sha256sum is not found the shasum tool is used instead. I have also tested on an older FreeBSD install (11.4) which does not include the sha256sum tool and everything works as expected.

Additional context
Since this is a bug specific to newer versions of FreeBSD, I am unsure how best to resolve this issue which is why I am opening a bug instead of submitting a PR to correct it. It may make more sense to simply use only the shasum tool on the FreeBSD platform, or it may make more sense to simply try that tool first in all cases? I'm happy to do the PR for whatever the discussion of this issue feels is appropriate.

Describe the bug

After, go get and reshim, the downloaded binary is placed in $HOME/go/bin and no shim of the binary is present, so the binary is not found in $PATH.

To Reproduce

$ cat .tool-versions 
golang 1.13

$ which go
/home/tom/.asdf/installs/golang/1.13/go/bin/go

# Clean everything in `$HOME/go`
$ rm -rf ~/go

# Install qtc using "go get"
$ go get -u github.com/valyala/quicktemplate/qtc
go: finding github.com/valyala/quicktemplate v1.6.2
go: downloading github.com/valyala/quicktemplate v1.6.2
go: extracting github.com/valyala/quicktemplate v1.6.2

$ asdf reshim golang

$ which qtc
qtc not found

# qtc has been installed in `$HOME/go/bin`
$ ll ~/go/bin
total 3,5M
-rwxrwxr-x 1 tom tom 3,5M 2020-08-18 11:05 qtc*

Expected behavior

After go get + reshim, a shim should exist pointing to qtc

Desktop (please complete the following information):

• OS: Linux
• Version: asdf version v0.7.8-4a3e3d6
• Version: asdf plugin update golang --> master

It looks as though Go 1.9 is missing from list-all.

asdf list-all golang | grep 1.9 | wc -l 
0

However, since the install command doesn't attempt to read XML contents and just constructs the url, it works fine:

asdf install golang 1.9
...

I was originally looking at this because asdf latest golang (which uses list-all internally) is noticeably slower than some of my other asdf plugins. Looking at some hyperfine benchmarks, I see it takes around 5s to complete compared to nodejs (0.5s) and python/ruby (60ms).

I assume part of that is the extra processing for truncated data + XML handling.

I was wondering if asdf-golang could just access tags from one of golang's repos.

Looking at how some alternative version managers do this:

• gvm - logic using git ls-remote -t https://github.com/golang/go,

  • https://github.com/moovweb/gvm/blob/19365a6ab8ac4920234b2612c529eed2373299db/scripts/listall#L35
  • this implementation uses git and awk (both extra dependencies). awk can usually be replaced with other tools. git would depend on whether golang exposes data via GitHub API (curl-able)
  • logic is much simpler, which should also mean easier maintenance.
  • A basic variant of above combined with existing asdf-golang logic runs on my system in ~0.5s

    git ls-remote --tags https://github.com/golang/go "go*" \
      | awk -F/go '{ print $2 }' \
      | uniq \
      | sort -t. -k 1,1 -k 2,2n -k 3,3n -k 4,4n -k 5,5n \
      | tr '\n' ' '

  • EDIT: Another variant using GitHub API thru curl, grep, sed runs in ~0.25s. A couple asdf plugins that use GitHub API usually add logic for optionally using GITHUB_API_TOKEN probably to increase GitHub rate limits.

    curl --silent --location "https://api.github.com/repos/golang/go/git/refs/tags" \
        | grep '"ref".*go' \
        | mysed 's/.*go([0-9].*)",/\1/' \
        | uniq \
        | sort -t. -k 1,1 -k 2,2n -k 3,3n -k 4,4n -k 5,5n \
        | tr '\n' ' '
    

• g - logic using curl --silent --location "https://go.googlesource.com/go/+refs"

  • https://github.com/stefanmaric/g/blob/1a9a135d07975c2ba804ddfae9a4089c9773ffe4/bin/g#L348
  • this implementation uses curl and grep/tr (same dependencies).
  • logic is again much simpler
  • A variant using the defined mysed runs on my system in ~0.4s.

    curl --silent --location "https://go.googlesource.com/go/+refs" \
      | grep -E -o '"/go/\+/refs/tags/go.+?"' \
      | mysed 's/.*go([0-9].*)"$/\1/' \
      | uniq \
      | sort -t. -k 1,1 -k 2,2n -k 3,3n -k 4,4n -k 5,5n \
      | tr '\n' ' '

Comparing the output, it looks like the above options include some older versions of go from v1 up to v1.2.1.

Describe the bug

When querying latest with a version filter, per the docs, it should accept one argument, a filter, and apply that filter to the list of versions, returning the latest version which matches.

To Reproduce

$ asdf latest golang 1.15
1.17.7

Expected behavior

$ asdf latest golang 1.15
1.15.15

Screenshots

N/A

Desktop (please complete the following information):

OS: macOS 12.2.1 x86_64
SHELL: zsh 5.8 (x86_64-apple-darwin21.0)
ASDF VERSION: v0.9.0
ASDF Golang Plugin: https://github.com/kennyp/asdf-golang.git master 353cca6

Additional context

N/A

How are other people handling integration with other tools, .e.g, vim-go? Running commands like :GoInstallBinaries are fine because they run go and then figure out the GOPATH, but :GoDef expects a GOROOT and fails. Not saying that this is an issue for this tool to resolve, just presumably I'm not the first person to run into this problem.

Describe the bug
tried go get github.com/pilu/fresh and fresh. Got command fresh not found

To Reproduce
Steps to reproduce the behavior:

1. Install andy cli via go get and run the cli

Expected behavior
Cli should e invoked

Screenshots
Screenshot: https://i.imgur.com/D9UU7Pv.png

Desktop (please complete the following information):

• OS: [e.g. iOS]
• Browser [e.g. chrome, safari]
• Version [e.g. 22]

Smartphone (please complete the following information):

• Device: [e.g. iPhone6]
• OS: [e.g. iOS8.1]
• Browser [e.g. stock browser, safari]
• Version [e.g. 22]

Additional context
Add any other context about the problem here.

Describe the bug
asdf-vm/asdf#762
Since this change of asdf core, asdf list golang may call parse-legacy-file script internally.
parse-legacy-file script invokes asdf list golang.
The result is an infinite recursive call.

To Reproduce
Steps to reproduce the behavior:

1. Install head version of asdf
2. mkdir example; cd example; go mod init example.com/m
3. asdf list golang
4. Command hung(infinite recursive call).

Expected behavior
Show the version and exit.

Desktop (please complete the following information):

• OS: Linux
• asdf version: v0.10.2-624aede
• asdf-golang cc8bc47

Describe the bug
When trying to reference GOPATH or GOBIN or GOHOME, all these variables are missing.

To Reproduce
Steps to reproduce the behavior:

1. Go to your source directory containing whatever code
2. run go env GOBIN and nothing is returned.
3. run go env GOPATH and the path leaves out the 'go' folder after the version and before whatever folder is next
4. returns /Users/user/.asdf/installs/golang/1.13.7/packages which doesn't actually exist

Expected behavior
would expect go env GOPATH to return /Users/user/.asdf/installs/golang/1.13.7/go and go env GOBIN to return `/Users/user/.asdf/installs/golang/1.13.7/go/bin

Screenshots

Desktop (please complete the following information):

• OS: MacOs 10.15.3

ASDF Version

• v0.7.6

Describe the bug
On Windows 11 with WSL2 (Ubuntu 20.04 LTS) asdf install golang fails silently.

It only prints out:

$ asdf install golang
Platform 'linux' supported!

When I look into directories:

• .asdf/installs/golang/
• .asdf/downloads/golang/1.18.1/

there are no files in them, they are just empty.

To Reproduce
Steps to reproduce the behavior:

1. On WSL2 (Ubuntu 20.04 LTS)
2. Type asdf install golang
3. Wait for it to finish its job.
4. See there are no files in installs and downloads directories of asdf

Expected behavior
asdf install golang installs golang successfully.

Screenshots
If applicable, add screenshots to help explain your problem.

Desktop (please complete the following information):

• OS: Windows 11 (21H2 / 22000.556)
• Browser: chrome
• Version: 100.0.4896.127

Additional context
Add any other context about the problem here.

Describe the bug
Can't get the default packages to be installed by following the readme... go get is deprecated, it is supposed to be using go install, tried to figure out how to do it with go install but my knowledge in go is really limited (just getting started)

To Reproduce

1 - Follow the README Default go get packages section
2 - Error message

go: go.mod file not found in current directory or any parent directory.
	'go get' is no longer supported outside a module.
	To build and install a command, use 'go install' with a version,
	like 'go install example.com/cmd@latest'
	For more information, see https://golang.org/doc/go-get-install-deprecation
	or run 'go help get' or 'go help install'.

Expected behavior
The default packages being installed.

Additional context
Tried to figure out how to make it work to update de README.md myself but failed... Thank you for the plugin

Can't access install go package executables.

Running on Ubuntu 16.04.
asdf v0.4.2

Steps to reproduce:

• Install a <version> of go
• asdf local golang <version> or asdf global golang <version>, doesn't matter
• go get -u <some package>
• Try to run that package

Tried with version 1.4, 1.5, 1.9 with the package mvdan.cc/sh/cmd/shfmt

Describe the bug
My asdf-golang installation seems to be picking the wrong go version for a project.
It is:
a) Picking the version from the go.mod file that is present, but the incorrect version
b) Ignoring the .tool-versions file present in the parent directory

I suppose b) is normal behavior IF the go.mod file takes precedence over .tool-versions present in the closest parent directory.

To Reproduce
Steps to reproduce the behavior:

1. mkdir project
2. cd project
3. asdf local golang 1.17
4. mkdir test
5. cd test
6. go version > 1.17 (as expected
7. go mod init test
8. go version > 1.18

in 8, asdf current takes the go version from the go.mod file, but the go.mod file shows 1.17

Expected behavior
asdf-go picks the correct version from the go.mod file and remains at v1.17

Screenshots

Desktop (please complete the following information):

• OS: WSL2 on Windows 11
• Browser: Firefox

Describe the bug
when running go version this is the output I see.

$ go version
/home/aaronreisman/.asdf/lib/utils.bash: line 234: ASDF_.._VERSION: invalid variable name
go version go1.16.6 linux/amd64

To Reproduce
Steps to reproduce the behavior:

1. Go to '...'
2. Click on '....'
3. Scroll down to '....'
4. See error

Expected behavior
no error

Screenshots
If applicable, add screenshots to help explain your problem.

Desktop (please complete the following information):

• OS: [e.g. iOS]
• Browser [e.g. chrome, safari]
• Version [e.g. 22]

Smartphone (please complete the following information):

• Device: [e.g. iPhone6]
• OS: [e.g. iOS8.1]
• Browser [e.g. stock browser, safari]
• Version [e.g. 22]

Additional context
Add any other context about the problem here.

this doesn't seem to work for me. tried on a new install:

adam@macbook ~ % . $(brew --prefix asdf)/asdf.sh
adam@macbook ~ % asdf plugin remove golang
adam@macbook ~ % asdf plugin add golang
adam@macbook ~ % cat ~/.default-golang-pkgs
golang.org/x/tools/...
adam@macbook ~ % asdf install golang 1.13
Platform 'darwin' supported!
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
100  115M  100  115M    0     0  29.3M      0  0:00:03  0:00:03 --:--:-- 29.3M

Installing golang.org/x/tools/... go pkg... /Users/adam/.asdf/plugins/golang/bin/install: line 78: go: command not found
FAIL

adam@macbook ~ % ls -la ~/.asdf/installs/golang/1.13/go
total 352
drwxr-xr-x   20 adam  staff    640  4 Sep  2019 .
drwxr-xr-x    3 adam  staff     96 31 Jul 22:34 ..
-rw-r--r--    1 adam  staff  55389  4 Sep  2019 AUTHORS
-rw-r--r--    1 adam  staff   1339  4 Sep  2019 CONTRIBUTING.md
-rw-r--r--    1 adam  staff  84339  4 Sep  2019 CONTRIBUTORS
-rw-r--r--    1 adam  staff   1479  4 Sep  2019 LICENSE
-rw-r--r--    1 adam  staff   1303  4 Sep  2019 PATENTS
-rw-r--r--    1 adam  staff   1607  4 Sep  2019 README.md
-rw-r--r--    1 adam  staff    397  4 Sep  2019 SECURITY.md
-rw-r--r--    1 adam  staff      6  4 Sep  2019 VERSION
drwxr-xr-x   19 adam  staff    608  4 Sep  2019 api
drwxr-xr-x    4 adam  staff    128  4 Sep  2019 bin
drwxr-xr-x   50 adam  staff   1600  4 Sep  2019 doc
-rw-r--r--    1 adam  staff   5686  4 Sep  2019 favicon.ico
drwxr-xr-x    3 adam  staff     96  4 Sep  2019 lib
drwxr-xr-x   16 adam  staff    512  4 Sep  2019 misc
drwxr-xr-x    6 adam  staff    192  4 Sep  2019 pkg
-rw-r--r--    1 adam  staff     26  4 Sep  2019 robots.txt
drwxr-xr-x   71 adam  staff   2272  4 Sep  2019 src
drwxr-xr-x  327 adam  staff  10464  4 Sep  2019 test

It seems that $ASDF_INSTALL_PATH is empty on the line:

PATH="$ASDF_INSTALL_PATH/bin:$PATH" go get -u $name > /dev/null && rc=$? || rc=$?

Originally posted by @adampetrovic in #29 (comment)

Hi,

When installing go via asdf-golang, I have found you need to update your $GOROOT environment variable as by default Go expects to be installed in /usr/local/go/, but asdf installs it into ~/.asdf/shims/go (well, ~/.asdf/installs/golang/ really).

Can we have $GOROOT automatically updated based on the go version in use in the project?

For how I discovered this, please see this issue.

Is your feature request related to a problem? Please describe.

Uninstall golang with asdf uninstall golang <version> fails if we have packages installed with go get command like below.

The reason of this failure is no write permission for directories and files under $ASDF_INSTALL_PATH/packages/pkg/mod installed with go get is 444 as below, so currently we need to explicitly add write permission before performing asdf uninstall golang <version>. This steps are complicated and specified version and its packages should be removed by asdf uninstall command.

Describe the solution you'd like

According to plugin guide, each plugin can have specific uninstall command. So packages should be removed completely if we have specific uninstall command that performs adding write permission (e.g. chmod -R u+wx $ASDF_INSTALL_PATH/packages) before removing $ASDF_INSTALL_PATH.

Hey there, I'm stucked with the problem: how could I use different go versions with different packages and imports to archieve some kind of gemsets that ruby can do.

I have an idea of changing $GOPATH env variable when I switch to different go version but I can't figure out what the actual path might be. Probably like:
$ASDF_INSTALL_PATH/../projects ?

Maybe we should handle $GOPATH globally from exec-env script to avoid going to ~/.asdf/install/go/version/projects and make us capable of just doing cd $GOPATH? Like create ~/.gopathrc and make it called from ~/.profile and parse first one each time exec-env is called...

Maybe you have another thoughts/suggestion/solution?

Thanks!

Describe the bug
asdf-golang is not selecting the expected version using only a go.mod

To Reproduce

➜  cat go.mod
module github.com/asdf-golang/issue

go 1.14
➜  asdf current golang
golang          1.17            /Users/jesse.brown/dev/jabrown85/go-test/go.mod
➜  asdf list golang
  1.14
  1.16
  1.17
➜  cat ~/.asdfrc
legacy_version_file = yes%

I know legacy_version_file is being respected given the output from go-test asdf current golang, but it seems to be picking the latest matching major version.

Expected behavior
I would expect go-test asdf current golang and subsequently go version to produce 1.14

Desktop (please complete the following information):

• OS: macOS 11.6

Is there any way we could have the $PATH environment variable modified to include the bin folder from the go packages folder based on the selected version?

Eg if you install realize:

go get github.com/tockins/realize

it creates a binary:
~/.asdf/installs/golang/1.10/packages/bin/realize

and you should be able to simply run the command realize (but you can't since the <selected go version>/packages/bin folder isn't in the path

Is your feature request related to a problem? Please describe.

ASDF allows for customizing the location of its data directories and configuration files (e.g., ASDF_DEFAULT_TOOL_VERSIONS_FILENAME) — this is useful for organizing user config files in accordance with the XDG base directory spec, which partly aims to keep dotfiles out of the home directory.

Although it's not a uniformly followed convention among plugin authors, several also provide this facility for default packages lists, for example:

• Ruby: https://github.com/asdf-vm/asdf-ruby#default-gems
• Python: https://github.com/danhper/asdf-python#default-python-packages
• Node: https://github.com/asdf-vm/asdf-nodejs#default-npm-packages

Describe the solution you'd like

When setting default_go_pkgs in install_default_go_pkgs, first attempt to read a path from an env var named ASDF_GOLANG_DEFAULT_PACKAGES_FILE.

https://github.com/kennyp/asdf-golang/blob/92a2e6108122d080f95114a5462ac0f787728544/bin/install#L31

Will submit a PR shortly.

Describe the bug
The go directive in the go.mod file does not indicate the Go executable version that should be used to build the project. In particular, the go tool explicitly works with versions other than the version in the go directive. Much of the language in the Go module reference suggests this to be the case:

A go directive indicates that a module was written assuming the semantics of a given version of Go.

For packages within the module, the compiler rejects use of language features introduced after the version specified by the go directive.

If an older Go version builds one of the module’s packages and encounters a compile error, the error notes that the module was written for a newer Go version.

Additionally, the go command changes its behavior based on the version specified by the go directive.

More evidence that the go directive is not prescriptive about the specific Go version that it should be built with is evidenced by a discussion about the possibility of incorporating a toolchain version into the go.mod file and go tool, independently from the existing directive: golang/go#55092

Additionally, this plugin's treatment of go.mod version selection explicitly conflicts with the rules provided by asdf:

Note that this script should be deterministic and always return the same exact version when parsing the same legacy file. The script should return the same version regardless of what is installed on the machine or whether the legacy version is valid or complete. Some legacy file formats may not be suitable.

This explicitly violates that spec rule by looking at the installed versions, and having no deterministic version resolution (e.g., what version should be used if go 1.20 is specified).

Because asdf does not allow enabling/disabling of specific legacy file formats on a per-tool basis, it is not possible to opt into the standard asdf treatment of legacy files without also opting into this plugin's non-standard interpretation of go.mod and the asdf functionality.

To Reproduce

1. Enable legacy_version_file = yes
2. Set a version of go with asdf global golang system (or other)
3. Open up a Go project with a go.mod file and no .tool-versions
4. The global asdf/golang version is not respected, because go.mod is incorrectly treated as a version file

Expected behavior
The global golang version will be chosen

Actual behavior
The go version is chosen non-deterministically based on the local go.mod file

Additional context
Broadly speaking, there are three ways to address this:

1. Remove the current behavior completely. This is my recommendation, as it keeps the plugin simple and conforms to standard go.mod and asdf spec interpretation
2. Make the current behavior opt-in, such as through use of an an environment variable (e.g., export ASDF_GOLANG_MOD_VERSION=true)
3. Make the current behavior opt-out, such as through use of an an environment variable (e.g., export ASDF_GOLANG_MOD_VERSION_DISABLED=true). I would personally not recommend this, because it requires configuration to prevent non-standard behavior

I'm happy to make the contribution, but I wanted to get buy in before starting work.