rtx doesn't update GOPATH in GoLand's terminal #815
Replies: 4 comments 23 replies
-
|
I'm pretty sure what is happening is Goland sets GOPATH itself. If rtx sets it before, then it feels at liberty to update it but if another tool (or zshrc) sets GOPATH then it does not screw with it. I inherited this behavior from the asdf plugin, but I'm not sure if it's wise or not. It seems there are use-cases where people want to have GOPATH overridden (or even set at all) and use-cases where they don't. What we could do is update this logic a bit to force GOPATH setting if RTX_GO_SET_GOROOT is true: https://github.com/jdxcode/rtx/blob/06f2bef728fc739e8668ce6b9c14134b697e8561/src/plugins/core/go.rs#L182-L198 I'd accept a PR for that. |
Beta Was this translation helpful? Give feedback.
-
|
huh I thought we had made a decision to default both of these to not be set by default, which I still think is what we should do even if it makes goland a bit tougher to configure. That seems to not be the case if the docs are correct though. But I agree with you that there should be an option to override, MISE_GO_SET_GOROOT=1 should not simply set it if it does not exist but also overwrite any existing value. |
Beta Was this translation helpful? Give feedback.
-
|
The fact the default sets GOROOT is making me think we shouldn't change the default, let me chat with the advisory board about this one. In other words we should keep setting the env var but tweak overwriting behavior I thought current behavior was the opposite |
Beta Was this translation helpful? Give feedback.
-
|
Looking at some of the history around this it seems there are reasons to set GOROOT explicitly even though I'm not sure I follow why people want to set GOBIN and GOPATH to the asdf directory though |
Beta Was this translation helpful? Give feedback.
-
|
Ok, right, I thought the behaviour was something else, too! Does look like this is really a matter of clearing up documented/intended/implemented behaviour. I was thinking of mise as always inheriting the host environment, and that it would never touch GOROOT if it were already set in the host environment. I.e. that regardless of what I do with MISE_GO_SET_GOROOT it will stick with the value set by GoLand terminal, meaning I have to make sure to unset it myself. Whereas, MISE_GO_SET_GOROOT=true solves my problem: [tools]
go = "1.22.0"
[env]
MISE_GO_SET_GOROOT="true"Now gives the result I expected in the GoLand terminal: The documentation claims that the default is true, but it doesn't seem to be then, I get a different behaviour by setting it explicitly to true? Maybe, even if default doesn't change, we can add a section to the documentation for GoLand users to suggest setting MISE_GO_SET_GOROOT=true in the .mise.toml? And for my own project I have a solution, so a big thanks for the discussion! |
Beta Was this translation helpful? Give feedback.
-
|
the docs certainly appear wrong: Lines 188 to 202 in e291cc3 I should have a new discussion on this topic with everything laid out soon though. EDIT: I linked to the wrong code sample the first time |
Beta Was this translation helpful? Give feedback.
-
Agreed, I think it's more helpful to keep these consistent. If a complex project needed to isolate built binaries, I'd just use "go build -o" and put them somewhere else |
Beta Was this translation helpful? Give feedback.
-
|
so I was driving and I think it hit me why people asked for this with asdf but I don't see anyone in that thread spelling this out so it's a bit of a guess. First, my understanding is there isn't any issue leaving GOPATH set to $HOME/go and switching go versions around. First I thought maybe the pkg directory might have version-specific stuff but that doesn't appear to be the case. Of course the src directory won't be version-specific either. I think people want this because of the bin directory—which is why they also talk about GOBIN. Recall that asdf is shim-based where with mise using shims is only an option used by a minority (albeit significant minority) of users. The behavior people are relying on is that when something is installed to I'll spell that out so it isn't clear: setting GOPATH is sort of a "trick" to get shims for go-installed CLIs which have GOROOT set. I don't think anyone actually needs or wants GOPATH to be modified except for setting GOROOT. I suspect this causes a lot of problems—in fact. With mise, this isn't really a problem at least for I plan to write a larger doc on GOPATH/GOROOT but right now I'm really unsure what the right path forward is at least for GOPATH. One option is to keep using GOPATH in ~/.local/share/mise/installs. This I feel is a pretty aggressive solution and probably causes a lot of problems by moving the src directory there. I don't like the current behavior. It does make shims that have GOROOT set though. Option 2 is to switch to GOBIN instead. This will create new shims for go-installed CLIs as well but won't mess with the src directory. I prefer this to 1 but still dislike that every time you switch go versions you'll lose anything you go-installed. That said, perhaps the go backend is more the right way to handle global CLIs anyways. Option 3 would be to stop doing either. I think I'm leaning towards 2 here. That said, I am not a go dev so will lean on the community for some guidance here. Also this goes without saying but it's more evidence that my gut saying "just let Also, if people have an example of a tool that relies on GOROOT and doesn't use |
Beta Was this translation helpful? Give feedback.
-
|
I think that's all very fair. The only thing to add, really, is that go install itself breaks if the GOROOT doesn't match to go version of the go command. So even putting any broken third party tools aside, the correct behaviour can only be achieved IMHO if we either:
or
Sounds like other people are running into a need for the second option. But for what broke my build, either option solves the thing. I just can't think of a good reason to point GOROOT somewhere other than the go tool you're running, so why ever inherit it from the host environment? If somebody really wants to do that -- then sure we can given them a setting. But honestly, that's the weird workflow. It just... doesn't seem safe by default because there's no logic in sharing GOROOT across go installations. It's literally meant to point to the go installation. Same with most tools, I would think? e.g. bad things happen when JAVE_HOME is pointing to something that is not, in fact, the java version you're using. (edited for clarity) |
Beta Was this translation helpful? Give feedback.
-
can you provide some color on this? an example would be helpful if you can think of one
"always" is a dangerous word. I think "by default" is probably the right way to go. What I'm leaning towards is not what happens currently where it is ignored if set but overwritten if set unless some other setting like MISE_GO_SET_GOROOT is explicitly set to false or something. I also don't know of a use-case where people would want a different GOROOT but I'm nervous about making assumptions like that. |
Beta Was this translation helpful? Give feedback.
-
Sure, so if the GoLand terminal GOROOT and path is pointing to go 1.21.6, and then I run mise where I've got it set for 1.22.0, the result is failure: What's happening, is that MISE is honouring the go tool version, but then it's also trying to honour the terminal GOROOT. But the two don't belong together, so the build fails. This is reproducible after a mise implode. I can sort-of fix this with: Which I didn't expect to make any difference, because documentation claims this is the default. Though, the environment doesn't seem to apply first time, so I end up having to run my build twice. Second time, mise picks up that it should set the GOROOT. But that's another issue, I guess.
Fair, maybe I worded it poorly. All I really mean is: by default, mise should disregard the host GOROOT value, because it almost never makes sense for GOROOT to differ from the actual go tool being executed I'd go so far as to say it never makes sense at all. What use case for GOROOT to be misconfigured? But, it seems harmless to have an option for it.
Not sure if we're on the same page about what the current behaviour is -- ignored if set? That would give me the behaviour I want! I have reproduced the behaviour above with serveral mise implodes. I'm confident that the default behaviour is that it does inherit the GOROOT and that results in the weirdness above |
Beta Was this translation helpful? Give feedback.
-
|
ok I finished my new doc that should hopefully lay this out with a clear path forward: #1638 |
Beta Was this translation helpful? Give feedback.
-
|
Honestly, that's an awesome write-up! Looks good to me. I'll read it again soon to make sure I didn't miss anything, and pick this up on #1638 itself (not a Rust developer but at the least, I can offer to test) Thanks for the great discussion! |
Beta Was this translation helpful? Give feedback.
-
|
thank you! this was certainly a gap and while I'm surprised it's been out for this long I think this will give mise users a better DX for sure! |
Beta Was this translation helpful? Give feedback.
-
|
For what it's worth, since the Go added forward compatibility and toolchain management in go1.21 (blog post) I stopped trying to mess my environment, just installed go1.21 once and called it a day. I still use mise for env variables and python though :) |
Beta Was this translation helpful? Give feedback.
-
|
yeah I saw that the other day. It certainly sounds like go devs are better off not using mise (like my guidance for rust), but I suspect some will want to use it at least for possibly getting the first version of go installed. Also, the go backend definitely still makes a lot of sense even with GOTOOLCHAIN. I should dive into that more and come up with either good guidance in the docs or see if there is anything we can leverage to make mise integrate better with go. This is a very good topic for a new discussion if anyone wants to start that off. |
Beta Was this translation helpful? Give feedback.
-
I just want to side-note that installing go is surprisingly easy: all it takes is untaring an archive and adding a directory to the path 😀 |
Beta Was this translation helpful? Give feedback.
-
|
That's a great tip, and very fair. Only caveat and why I continue to investigate mise for the go toolchain, is that if you want serious reproducibility, you'd want it to pin the exact version, not just set a minimum. So that everyone is using the same version to build a given project, and that updating is a Merge Request on the project. Unfortunately that only seems to happen if you force the toolchain with the environment variable approach, e.g.: Unless I missed a feature of the toolchain in go.mod to do this, I'd still end up having to manage the environment to do this. Still, I might give it some more thought! |
Beta Was this translation helpful? Give feedback.
-
I also think mise is overkill for just installing a single version of a tool, but there are certainly a lot of users that do like working that way. I think one reason is they like a single ".tool-versions" file that has everything in it so a vanilla system can just use It's worth thinking about that use-case, rust has a similar thing going on with rustup too. It may make sense to have the concept of "singleton tools" that are version-managers themselves that mise can integrate with more directly. |
Beta Was this translation helpful? Give feedback.
-
That’s a perfectly valid use case and as far as I can tell from the blog post and documentation, I believe you’re correct.
You could use mise to set the env variable 😛😁 Another side note: the Go team puts a lot of efforts into backwards compatibility as well, and there have been interesting developments since. In 1.22, the loop variable behavior changed ; but this is only applied when compiling with go1.22 on a project that lists go1.22 in the go.mod. When compiling a project listing go1.21 with a 1.22 toolchain, the old behavior is preserved. As you said, it doesn’t solve the perfect reproducibility issue, but IMO it’s good enough for the majority of go devs.
That's another valid use-case 👍🏻 |
Beta Was this translation helpful? Give feedback.
-
I'm using rtx with fish, it works fine in my usual terminal emulator but fails to update GOPATH and GOROOT in GoLand's integrated terminal emulator.
However, if I launch GoLand from the shell script provided with the JetBrains Toolbox, it works fine.
I have setup
rtx activatein my fish, bash and zsh config:Did I miss something in my config? Is it a known issue? I read the README about IDE integration but it looks like it applies to running binaries from the IDE, not from terminal emulators in the IDE.
In iTerm2
In Goland (opened as a normal app)
In Goland (opened with the shell alias)
Adding "IntellIJ IDEA" for search purposes.
Beta Was this translation helpful? Give feedback.
All reactions