You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Rust and now Go both have first-class version-managers. In rust, this is managed by a tool called rustup and in go it's built into go1.21+ toolchains directly.
These offer better DX than what mise likely could ever accomplish and I think people in general should use them for managing go/rust versions and not mise. That said, mise is still something users may want to use alongside them because it solves the bootstrapping problem. They can just run mise install to install go/rust alongside whatever else their project requires without separately installing rustup or any supported version of go.
I'd like mise to really be thinking of this use-case and how it can best support it. The current model where each tool version shares nothing with other versions does not work as well. This may just mean that they would typically only go into the global config but it's worth thinking about other potential solutions too.
Like maybe "singleton tools" where mise only ever has 1 version is a good idea. Dunno.
Rust
With rust, because rustup is a separate tool, this could simply be a matter of a rustup plugin. You install it via mise use -g rustup@latest and update rustup itself with mise up rustup but rust versions would just be managed via rustup. In this case, I think it makes sense to use ~/.cargo as the rust toolchain directory so these don't get lost during rust updates.
What this would lack though is the ability to see the current version of rust with commands like mise ls or updating rust with mise up. I would like to see plugins be able to offer some tighter integration here where a plugin could provide versions itself. Perhaps the "forge" concept used for backends could be leveraged here. I say "plugin" but at least in the case of rustup I think this should actually go into the core of mise since rust is certainly popular enough to warrant being in core.
Go toolchains
Go toolchains work differently since they're baked into go itself. This means that we don't need a new plugin, users can just rely on the current go core plugin and start using toolchains today.
The only notable problem is that mise defaults to modify GOPATH which means that changing the global go version would cause all of the toolchains to also be lost which is discussed at length in #1638. It looks like go uses GOPATH/pkg in particular for managing the toolchains and doesn't put anything into GOBIN (thankfully). This means the proposed solution there will work for toolchains.
This would benefit from similar tighter integration with mise for things like mise ls and mise up though. There is also the concept of "+auto" tags on toolchains which (if I understand right) will use either the version specified or the lowest version compatible with what is in go.mod. Frankly I'm not sure I even really understand what that is for or how users might use it in or out of mise at first glance. I guess the idea is "I want this version, but if nothing else give me the closest thing that the project can use." I'm not sure I can think of ever needing something like that though—nor a mise user ever asking for anything like it.
reacted with thumbs up emoji reacted with thumbs down emoji reacted with laugh emoji reacted with hooray emoji reacted with confused emoji reacted with heart emoji reacted with rocket emoji reacted with eyes emoji
-
Rust and now Go both have first-class version-managers. In rust, this is managed by a tool called rustup and in go it's built into go1.21+ toolchains directly.
These offer better DX than what mise likely could ever accomplish and I think people in general should use them for managing go/rust versions and not mise. That said, mise is still something users may want to use alongside them because it solves the bootstrapping problem. They can just run
mise install
to install go/rust alongside whatever else their project requires without separately installing rustup or any supported version of go.I'd like mise to really be thinking of this use-case and how it can best support it. The current model where each tool version shares nothing with other versions does not work as well. This may just mean that they would typically only go into the global config but it's worth thinking about other potential solutions too.
Like maybe "singleton tools" where mise only ever has 1 version is a good idea. Dunno.
Rust
With rust, because rustup is a separate tool, this could simply be a matter of a rustup plugin. You install it via
mise use -g rustup@latest
and update rustup itself withmise up rustup
but rust versions would just be managed via rustup. In this case, I think it makes sense to use ~/.cargo as the rust toolchain directory so these don't get lost during rust updates.What this would lack though is the ability to see the current version of rust with commands like
mise ls
or updating rust withmise up
. I would like to see plugins be able to offer some tighter integration here where a plugin could provide versions itself. Perhaps the "forge" concept used for backends could be leveraged here. I say "plugin" but at least in the case of rustup I think this should actually go into the core of mise since rust is certainly popular enough to warrant being in core.Go toolchains
Go toolchains work differently since they're baked into go itself. This means that we don't need a new plugin, users can just rely on the current go core plugin and start using toolchains today.
The only notable problem is that mise defaults to modify GOPATH which means that changing the global go version would cause all of the toolchains to also be lost which is discussed at length in #1638. It looks like go uses GOPATH/pkg in particular for managing the toolchains and doesn't put anything into GOBIN (thankfully). This means the proposed solution there will work for toolchains.
This would benefit from similar tighter integration with mise for things like
mise ls
andmise up
though. There is also the concept of "+auto" tags on toolchains which (if I understand right) will use either the version specified or the lowest version compatible with what is in go.mod. Frankly I'm not sure I even really understand what that is for or how users might use it in or out of mise at first glance. I guess the idea is "I want this version, but if nothing else give me the closest thing that the project can use." I'm not sure I can think of ever needing something like that though—nor a mise user ever asking for anything like it.Anyone have any thoughts here?
Beta Was this translation helpful? Give feedback.
All reactions