`mise rm`
jdx opened this issue · 11 comments
right now mise rm|remove
is an alias for mise uninstall
, however I am wondering if that should stay the case. I am considering whether it should have slightly different behavior where instead of just uninstalling a tool, it would also modify the config file to no longer reference the installed tool. Basically the inverse of mise use
.
New users—notably this is a problem specific to those not coming from asdf—are becoming confused why they can't "completely remove" something. What they do is something like this:
$ mise use -g node@20
$ mise uninstall node
$ mise ls
node 20.0.0 (missing)
node shows up as v20 with a "missing" tag on it but they just uninstalled it.
Now for asdf users, they don't struggle here. They know that mise install|uninstall
do not touch config files but mise global|local
do. It wouldn't make sense for mise uninstall
to have done that.
This was introduced when I created mise use
which doesn't have a discoverable inverse command. To illustrate, the matrix of commands looks like this:
add | remove | |
---|---|---|
does not modify config | mise install |
mise uninstall |
does modify config | mise use |
mise ??? |
Although, technically that isn't quite true, there are 2 commands for this task:
mise global|local --rm
mise use --rm
But they both have problems. First, global|local
is something I actually push users away from for DX reasons. It's asdf legacy support. mise use
is almost always a better option. mise use --rm
isn't great though because it just sounds weird and users wouldn't think to look under mise use
for removing something from config.
I think what would make sense is a new command: mise rm
. However, I really dislike introducing yet another command that's only slightly different. I worry about confusion between mise uninstall
and mise remove
. Perhaps in the beginning it would've made sense to completely break away from asdf's convention and only have mise install|uninstall
and have both of them modify config files unless some flag was passed, but I'm not sure.
I'm leaning towards thinking we should add it. I think my table above illustrates that it's a fairly clear gap. However I tried to think the logic for that command through and it's actually quite complicated. What if something is defined in multiple config files? Do you need to specify mise rm --global
if it's only in the global config? Lots of outstanding questions.
Perhaps to avoid confusion I could call it the awkward—but more clear—mise unuse
.
How about mise unuse
and deprecate mise rm|remove
?
It's also surprising that "remove" doesn't have a complimenting "add".
I think mise unuse
is more clear :)
Hey, just a random user of asdf and now mise, here. Thanks for your work on mise -- I love it so far!
I have a bit of a fringe take on this: Remove editing the .tool-versions
file completely from the CLI, including mise use
.
My reasons for this are:
- Adding and editing .tool-versions very easy for a human to change themselves: the format of .tool-versions is pretty simple and understandable. It's very terse, as well.
- Editing .tool-versions doesn't happen very often: only when upgrading or adding a new tool. Most large, professional applications I've worked on are slow at this. This may be less true for codebases where the developers are more militant about upgrading patch versions.
- These are extra commands that are only there to do something very simple. The best CLIs, in my opinion, are ones that have a smaller "surface area", less commands and less flags, but do something very complex under the hood.
Contrary: I really appreciate editing the .mise.toml
with mise use, especially that it can understand which files I want to edit, and resolve to the specific versions without me having to first identify the specific version and manually edit it myself, if I ask it to.
I second mise unuse
as a intuitive command for this. mise rm
seems a bit opaque to me in general (whether for "unusing" or for "uninstalling").
I think it would also be a good idea to add status logs when using mise uninstall
(or even mise install
) that identify to the user that the tool is being uninstalled but that doesn't mean the "requested tool" is changing. For mise install
, it can tell the user that just because the tool is installed globally, doesn't mean it's actually resolved (because it isn't specified or preferred in .mise.toml
globally or locally).
I was thinking mise clear
might be a good name for "remove tool from config file".
I was also thinking an uncommon synonym for “remove” might be a way to introduce “unuse” in a way that reads better in English even if it’s not a common word in CS like “rid”, “abandon”, “fire”, “sack”.
I think some clearer logs is another great idea. I have attempted to align on a shorthand notation for tools generally but I should probably amend that to also include the action taken.
What about "forget"? e.g. mise forget node
to me "forget" would mean "remove from config but not the install", similar to mise clear
. That doesn't encapsulate what I would like which is a true inverse of mise use
. Maybe it's ok though, since having something installed but not in use isn't really a big deal. We could always have mise clear --rm
or mise forget --rm
.
That said, I do like the cuteness of potentially changing mise use
to mise hire
and then having mise fire
(with a mise sack
alias for UK users).
mise purge
I like mise clear
. Another suggestion could be mise prune
, but in any case I think this would be a worthwhile command to have.
mise unuse
seems appropriate here.
But, as precisely the sort of newbie that you're addressing with this, could you also please elaborate on why someone would or would not want to mise uninstall
vs mise unuse
?
Or, more specifically, why do mise install
and mise uninstall
even exist? Why would you want to add/remove without affecting the config? I'm sure there are good reasons, but I don't see them yet. Thanks!
mise install
without arguments certainly is useful if you're reusing an existing config. mise install
with args is asdf behavior that was ported and certainly is not possible for us to remove or reconsider at this point. Too many people rely on that behavior even if it's not the most obvious DX.