[Bug] go debugging doesn't work

[rotty3000]

Describe the bug
I can't get go debugging working with only the wrapper.

To Reproduce
try ./gow get github.com/go-delve/delve/cmd/dlv@latest and the install fails because go is not on the path. This might be related to #7 ?

Expected behavior
install succeeds.

Please complete the following information:
Doesn't seem to matter which env.

Additional context
Here's a log of the process I used:

]$ ./gow get github.com/go-delve/delve/cmd/dlv@latest
go: downloading github.com/cpuguy83/go-md2man/v2 v2.0.2
go: downloading github.com/russross/blackfriday/v2 v2.1.0
go: added github.com/cosiner/argv v0.1.0
go: added github.com/derekparker/trie v0.0.0-20200317170641-1fdf38b7b0e9
go: added github.com/go-delve/delve v1.9.1
go: added github.com/go-delve/liner v1.2.3-0.20220127212407-d32d89dd2a5d
go: added github.com/google/go-dap v0.6.0
go: upgraded github.com/mattn/go-runewidth v0.0.2 => v0.0.13
go: added github.com/rivo/uniseg v0.2.0
go: added go.starlark.net v0.0.0-20220816155156-cfacd8902214
go: added golang.org/x/arch v0.0.0-20190927153633-4e8777c89be4
go: upgraded golang.org/x/sys v0.0.0-20220722155257-8c9f86f7a55f => v0.0.0-20220811171246-fbc7d0a398ab
]$ ls -l .go/wrapper/go/bin/
total 26964
-rwxrwxr-x 1 rotty rotty  8924499 Sep 25 14:42 cobra-cli
-rwxr-xr-x 1 rotty rotty 15296123 Aug 31 13:40 go
-rwxr-xr-x 1 rotty rotty  3386361 Aug 31 13:40 gofmt

It seems like they landed in the OS GOBIN and not the project GOBIN

[rotty3000]

FYI this was tested against https://github.com/furkilic/go-wrapper/tree/7-feature-enable-installing-binaries

[furkilic]

Hi @rotty3000

Can you show me the output of ./gow printenv

I am suspecting that you are using the default GOPATH env vairable set by go ( which is $HOME/.go)
You might need to override your GOPATH in your desired path before using gow ( in your case export GOPATH=$PWD/.go/wrapper/go

[rotty3000]

]$ ./gow printenv
export GOROOT="/home/rotty/projects/lcectl/.go/wrapper/go"
export GOPATH="/home/rotty/go/bin"
export PATH="$GOROOT/bin:$GOPATH/bin:$PATH"

# Run this command to configure your shell:
# eval "$(./gow printenv)"

But shouldn't the wrapper ensure that any sub invocation has the correct GOPATH?

[rotty3000]

I think there should be a flag I can set in .go/wrapper/go-wrapper.properties that says "Don't use the outside GOPATH".

[furkilic]

]$ ./gow printenv
export GOROOT="/home/rotty/projects/lcectl/.go/wrapper/go"
export GOPATH="/home/rotty/go/bin"
export PATH="$GOROOT/bin:$GOPATH/bin:$PATH"

# Run this command to configure your shell:
# eval "$(./gow printenv)"

But shouldn't the wrapper ensure that any sub invocation has the correct GOPATH?

Indeed it ensures that any sub invocation done through gow has the correct GOPATH
The question might be what is the correct GOPATH ?

• by default, the correct GOPATH is the default GOPATH provided by go (ie $HOME/go)
• if you override it export GOPATH="/home/rotty/projects/lcectl/.go/wrapper/mypath" , this is what will be used.

Another point is all the tools you'll install (so in GOPATH/bin) will be accessible to gow but not directly to your shell, so you'nt be able to use dlv directly, to make it happen you'll need to use eval "$(./gow printenv)" then the magic will happen

I think there should be a flag I can set in .go/wrapper/go-wrapper.properties that says "Don't use the outside GOPATH".

yes you might create a new feature request for that purpose