Local defaults for --tty and other command line options

[nirs]

Description

My workflow is:

1. Create a lima yaml, usually for testing something, by copying another yaml and editing it. I want to keep the yaml around for creating more vms later, maybe put in in version control.

2. Create the vm from the yaml

I never want to edit the yaml during creation, but I forget to add --tty=0 a lot. Editing the yaml means your changes are saved only in ~/.lima/name/lima.yaml, and I like to treat anything under ~/.lima as ephemeral.

It would be useful if --tty=false was the default, but this may not be best for everyone. Having a local default will make it easy to adapt lima to different users. This option name is also not great, it should be about editing the yaml, not about using in a terminal.

Current behavior is to default to tty=true when using in a terminal:

rootCmd.PersistentFlags().Bool("tty", isatty.IsTerminal(os.Stdout.Fd()), "Enable TUI interactions such as opening an editor. Defaults to true when stdout is a terminal. Set to false for automation.")

We can change it to:

• read a configuration file (e.g. ~/.lima/_config/local.yaml)
• consider the local default for tty and the terminal capabilities

[jandubois]

The canonical way to add config file and env var support to a cobra app would be to use viper.

[afbjorklund]

Having somewhere to store global Lima defaults like that would be handy, beyond the env var.

[AkihiroSuda]

Why not just set alias limactl=limactl --tty=false?

[jandubois]

Why not just set alias limactl=limactl --tty=false?

That's a good idea!

Having somewhere to store global Lima defaults like that would be handy, beyond the env var.

What are those global Lima defaults that you want to set? Defaults for anything in lima.yaml can go into $LIMA_HOME/_config/default.yaml. What else is there that you want to set globally? I see --debug, --log-level and --log--format, and they can squeeze into the alias as well.

[nirs]

Having somewhere to store global Lima defaults like that would be handy, beyond the env var.

What are those global Lima defaults that you want to set? Defaults for anything in lima.yaml can go into $LIMA_HOME/_config/default.yaml. What else is there that you want to set globally? I see --debug, --log-level and --log--format, and they can squeeze into the alias as well.

OK, so we already have a place for defaults and we can add more defaults there.

[nirs]

Why not just set alias limactl=limactl --tty=false?

This is a good workaround, but I don't like to use aliases. One issue is having to manage the aliases on every user account on every machine, other is conflicts if you want to enable the feature disabled by the alias.

[jandubois]

One issue is having to manage the aliases on every user account on every machine,

You have the same issue with any other shell configuration. This is normally solved by

• putting your dotfiles into Git and using one of the many dotfile managers, or
• putting your config on a shared network drive or cloud service (e.g. Dropbox) and symlink to them

other is conflicts if you want to enable the feature disabled by the alias.

That is not an issue, later options override earlier options:

$ type limactl
limactl is aliased to `limactl --tty=false'

$ limactl start --tty template://alpine
? Creating an instance "alpine"  [Use arrows to move, type to filter]
> Proceed with the current configuration
  Open an editor to review or modify the current configuration
  Choose another template (docker, podman, archlinux, fedora, ...)
  Exit

[afbjorklund]

OK, so we already have a place for defaults and we can add more defaults there.

It is only for the template defaults, and it is local to the LIMA_HOME (not HOME)

I meant something like a .limarc, that you would normally put in XDG_CONFIG_DIR

Historically we didn't use shell aliases because there were "too many" shells (i.e. two)

I guess that is three now, if we count the fish users. Also some tools had a GUI*, not CLI.

---

* I did create a config file for Lima GUI, but so far it doesn't have anything but "paths".

https://doc.qt.io/qt-5/qsettings.html#locations-where-application-settings-are-stored

[nirs]

I thought about ~/.config/lima/limactl.yaml. The advantage is separating instance configuration and command configuration.