Go related steps fail after another step updated go and removed the old version #1039
Open
2 of 6 tasks
Labels
C-bug
Something isn't working
Erroneous Behavior
I have go installed with mise, and I'm not really a go dev, so I installing it with mise is the most go action I've done in a while.
When I run topgrade and mise will update go, it also removes the previous installation (which is just what mise does, I suppose, nothing to do with topgrade).
However, when deciding on subsequent steps to do (namely,
go-global-update
andgup
), topgrade fails when trying to figure out of those steps should be run. I don't have either of those tools installed, and the fallback check of checkinggo env GOPATH
. This check now fails withExpected Behavior
I expected topgrade to skip the step, as it would on every other invocation when no go update happens.
Steps to reproduce
go version
returns the older version. Maybe alsohash -d go
and open a new terminal/shell to be sure.gup
orgo-global-update
installedtopgrade
Possible Cause (Optional)
Ultimately, this is more of a go/mise/caching issue.
I can open another terminal before running the update (e.g. where
go version
still points to 1.23).The I run topgrade in another terminal, hitting the issue.
In the first terminal I run
go env GOPATH
to get the same error:go: cannot find GOROOT directory: /Users/knut/.local/share/mise/installs/go/1.23.6
. However, after updating the binary cache (hash go
orhash -d go
), runninggo env GOPATH
succeeds.topgrade/src/steps/go.rs
Lines 33 to 43 in 66a12cc
utils::require(name)
will not find the tool, bututils::require("go")
will find go and the command on line 40 fails.Turning any error from running
go env
into a skip instead would likely fix this, but I'm not sure if it's a good idea in case ago env
error is actually due to something else.Also, I can "fix" it locally by adding
go
to themisc.disable
config (though, neithergo-global-update
norgup
are accepted there, onlygo
).It works for me, since I don't really care about go otherwise, but it feels a bit like too big of a hammer to use.
Problem persists without calling from topgrade
As mentioned above, I can reproduce the error of running
go env
.Did you run topgrade through
Remote Execution
If yes, does the issue still occur when you run topgrade directlly in your
remote host
Additional Details
macOS 15.3.1
homebrew
(which topgrade
->/opt/homebrew/bin/topgrade
)topgrade -V
)topgrade 16.0.2
Verbose Output (
topgrade -v
)The text was updated successfully, but these errors were encountered: