Allow command aliasing via PATH lookup
There have been several requests to add additional aliases to limactl commands, e.g. ps for list or ssh for shell.
Instead of adding more and more personal aliases into the app itself, I would like to see a generic command aliasing mechanism like git and kubectl already implement:
When a subcommand foo does not exist then limactl will look for limactl-foo on the PATH, and execute that program instead (passing all commandline arguments along).
Let's assume we add --running filter to the list subcommand, then a user could create limactl-ps:
#!/bin/sh
limactl list --running "$@"
Sounds like the right way!
Instead of adding more and more personal aliases into the app itself, I would like to see a generic command aliasing mechanism like git and kubectl already implement:
What are pros (and cons) of making them subcommands of git/kubectl/limactl, not independent commands?
The main reason for the subcommands is that people have claimed they expected a certain alias to work, so they just typed it subconsciously.
E.g. when working mostly with docker and using docker ps to list containers, it feels natural to run limactl ps to list machines.
When you make it a different command, you still have to think about it and type the correct command. Then you can also just remember to type limactl ls.
@nirs explained that the same happens to him that he types limactl ssh instead of limactl shell.
We discussed different ways to accomplish this on Slack, and using this plugin mechanism seems like a well established pattern and seems fairly simple to implement.
Aliasing ssh=shell should be fine and can be just implemented in the upstream, but aliasing ps=ls seems weird.
If we are going to have limactl ps, that should diverge from limactl ls and should print information specifically about running instances.
Added #3613 to get more input on this. This is also easy task for new contributors.
Aliasing
ssh=shellshould be fine and can be just implemented in the upstream, but aliasingps=lsseems weird.
I replied in #3613 why I think aliasing ssh to shell is also weird.
If we are going to have
limactl ps, that should diverge fromlimactl lsand should print information specifically about running instances.
Yes, but I don't think we should have a ps subcommand at all. We should add a --running option (and maybe --stopped or allow --running=false as well) to list.
But this issue is really about providing a plugin mechanism similar to git, gh, kubectl, docker, helm, kustomize, terraform (I'm sure there are plenty more).
The discussion about the specific examples is really a distraction; what is the argument why limactl should not support a similar plugin mechanism?
can this be assigned to me?
I also think the PATH lookup implementation should be documented but I am not sure if it should be done in this pr or in a separate one.
I also think the PATH lookup implementation should be documented but I am not sure if it should be done in this pr or in a separate one.
It would be best to start with the documentation to make sure we agree on how the feature will work before spending time on coding. This will also ensure that we don't forget to document this feature.
I also think the PATH lookup implementation should be documented but I am not sure if it should be done in this pr or in a separate one.
It would be best to start with the documentation to make sure we agree on how the feature will work before spending time on coding. This will also ensure that we don't forget to document this feature.
oh, I just opened a PR for it. I can always update based on how the conversation goes.
Reopening as:
limactl --helpandlimactl infoshould show the available pluginsPREFIX/libexec/limashould be scanned in addition to$PATH
This can be done in another pr right? @AkihiroSuda
This can be done in another pr right? @AkihiroSuda
The original PR was merged, so there is no other option.
This can be done in another pr right? @AkihiroSuda
The original PR was merged, so there is no other option.
I opened a PR for it.