$LIMA_HOME/_config/defaults.yaml not created by default

[nirs]

Description

Default lima _config looks like:

% tree ~/.lima/_config
/Users/nsoffer/.lima/_config
├── networks.yaml
├── user
└── user.pub

With this the defaults feature _config/default.yaml has no visibility:

• user doe now know that there can be such file
• user has no way to tell what are the defaults

This easy to fix by creating a defaults file when creating the _config directory.

Questions:

• Who owns the default file? should lima change the defaults file when a new version use new default values?
  • The canonical way to solve this on Linux is the defaults come from application/vendor/distro location and user does not own them. User defaults are installed in user own files and override the system defaults (e.g. conf.d/50-user.conf).

If the defaults.yaml is owned by the user it is fine to not create it, but there should be another defaults.yaml not owned by the user that can be copied to or use as a reference when creating user defaults.

[jandubois]

The default.yaml (and override.yaml) are owned by the user, and Lima should never modify them.

There are no reference files for them because the reference would be empty.

Once I'm done with the "multi-file templating mechanism"¹ I plan to document this in the website and not just inside template://default. Once that is done we can create empty default.yaml and override.yaml files with just a comment to the docs, if the files do not exist yet.

I wouldn't want to create the files just yet because once they exist, we should not touch them again.

---

We have a bigger problem with $LIMA_HOME/_config/networks.yaml, which has non-empty default content, and we can't really edit the file once it exists, even though Lima internals may require changes. Again, I don't want to think about this until the multi-file templating work is done.

Footnotes

1. I have a working implementation for the template assembly already, but I keep refactoring it. Also needs to be split into smaller pieces (may not really be possible though). ↩

[nirs]

Creating empty defaults.yaml and overrides.yaml with comments explaining the purpose of the files, how they are used, and linking to the place documenting all the options (template://default?) can be good enough to make this visible.

We can also log a message when creating the files like:

Created "~/.lima/_config/defaults.yaml", you can edit this file to ...    
Created "~/.lima/_config/overrides.yaml", you can edit this file to ...

We can also add _config/README with all the defaults, something like:
https://github.com/oVirt/ovirt-imageio/blob/master/data/README

We also add commands that edit the defaults/overrides/networks:

limactl config defaults
limactl config overrides
limactl config networks

Zed has very useful menu "Open Settings" that opens ~/.config/zed/settings.json. It is not hard to remember the path, but not having to remember this uninteresting detail is very nice. Same for project based settings .zed/settings.json.