Provide easy way to shell into the finch vm

[weikequ]

What is the problem you're trying to solve?. Currently, it is not user friendly and a big hassle to shell into the finch vm. I would like to be able to easily shell into the finch vm for debugging and customization instead of having to run LIMA_HOME=/Applications/Finch/lima/data /Applications/Finch/lima/bin/limactl shell finch

Describe the feature you'd like It would be good to have something like finch shell or finch vm shell to access the underlying finch vm.

[ningziwen]

Thanks for initializing this issue. There were some discussions about this in different places before and the issue is a good place to close on it.

I prefer not to enable Finch command to log into shell by default. Here is my thought process. The viewpoints below are just my personal recommendation and are not the official statements of Finch yet. Looking forward to gettting community input and hopefully we can settle down some of these principles at some point.

What should the scope of default Finch command (or even any external interfaces) be?

The default Finch commands is ideally a set that is specifically for Finch users to learn and use. It is targetted to accurately meet the scope of what users are expected to use (the scope is defined by user stories). Being smaller than the expected scope will not satisfy user's need. Being larger than the expected scope could increase the unnecessary learning cost of users to learn the things they should not use, and even mislead the approach of using Finch.

Is finch shell part of user stories?

For Finch or other similar container development tools, the user stories are always across the container development operations, such as build, run, push, pull. MacOS doesn't have the container primitive such as namespace and cgroup which causes the user stories can't be directly satisfied in macOS, so Finch macOS integrates the virtualization layer to make the user stories work in macOS. The virtualization layer is the technique behind the scene to support the user stories instead of part of user stories.finch shell will be a command only serving virtualization layer so it is not part of user stories.

Should users use finch shell in normal cases?

No. What users are expected to learn and use are just user stories and they don't have to invest time on learning any technique behind the scene. Additionally, logging into VM exposes to users the risk of corrupting Finch by manual operations. If users use Finch in a strict development environment where Finch should be always healthy to support their development, this risk can be significant.

Should users use finch shell when running into issues?

It depends. Today users sometimes need to log into VM to collect logs and send to support. However running into issues should be treated as rare cases, and may be assumed less and less as the project becomes mature. In addition, there is an ongoing PR to add support bundle, which may give the ability of collecting logs without logging into VM.

Should developers use finch shell?

Yes. Developers are different with users. Developers may be interested in any technologies behind the scene, and have to use them when they develop Finch. LIMA_HOME=/Applications/Finch/lima/data /Applications/Finch/lima/bin/limactl shell finch is not user friendly but is more acceptable to developers.

Instead of default, can we introduce finch shell in the non-default developer mode?

It may be a good idea at some point. However, adding developer mode for single command finch shell only may not be deserved now. Switching to developer mode and running finch shell may not be easier than LIMA_HOME=/Applications/Finch/lima/data /Applications/Finch/lima/bin/limactl shell finch. When we have multiple use cases to support developer mode, it could deserve the effort.

[sam-berning]

Been thinking about this a bit with https://github.com/runfinch/finch/issues/369, and wanted to add some of my thoughts here:

Is finch shell part of user stories?

For Finch or other similar container development tools, the user stories are always across the container development operations, such as build, run, push, pull. MacOS doesn't have the container primitive such as namespace and cgroup which causes the user stories can't be directly satisfied in macOS, so Finch macOS integrates the virtualization layer to make the user stories work in macOS.

There is already some precedent for Finch breaking this rule -- all of the finch vm subcommands deal with the virtualization layer, not with the container development layer. I agree with you that these are sort of a "necessary evil" in the CLI design, but adding finch vm shell doesn't break the scope of the finch command any more than those commands, imo.

Another option that would allow us to keep the scope of the finch command small while making it easier to shell to the VM would be to package another binary with Finch that manages this scenario, e.g. finch-shell.

Should users use finch shell in normal cases?

No. What users are expected to learn and use are just user stories and they don't have to invest time on learning any technique behind the scene.

I think this is a good argument that finch shell or similar shouldn't be required in the normal use case, but I don't think it's a good argument that we shouldn't make it easier. Making something easier to do doesn't guarantee that people will do it all the time, it simply removes some of the legwork required when a user needs to shell to the VM.

One example of a scenario that currently requires shelling to the VM is increasing vm.max_map_count for Elasticsearch. It's possible to build a different way to change this configuration, but we can't anticipate every use case a user might have. Making shelling to the VM more accessible seems like a good way to help unblock users that need unique setups while we work on a more native solution.

Developers are different with users.

I see your point with the distinction between Finch users and developers, but I think it's also important to keep in mind that Finch users are all developers as well. Obviously not in the sense that you intended -- that they develop actively on Finch -- but in the sense that they are working on solving hard technical problems. We can do our best to provide an opinionated set of tools, but users will run into scenarios that require tools that we haven't anticipated. Making access to the VM easier empowers users to solve these problems with Finch.