Suggestion: allow using "." in mount location and\or scripts

[centur]

Description

Hi, first - thanks for the great project, lima is a first thing that worked properly from the start on M1 Mac for me, 💯 👍 .

I'm trying to build dev environment for the project using lima-vm and found that I need somehow map dirs which are relative to lima yaml file. The scenario is to have a VM with installed tools (provisioning scripts work great for installing tools but not for adding configs) and configuration for tools from a repository. To achieve this I need some form of "relative" path to be mapped into vm on creation. There is an example of such path - ~ is expanded to user's home directory when used in mounts.location. Can we have something like . and .. or some other path expansion tokens, which would be expanded to a current template file directory, so during VM creation we can use something like:

mounts:
  - location: "./../config"
     mountPoint: /opt/hashicorp/config # will be supported in next version
     writable: false

to map certain folders from host to guest.

Technically it can be achieved today by specifying a location path relative to home, e.g. - location: "~/myprojects/project-name/devenv/config" but it's less portable as different developers may have different structure in their home dir.

Mount point is probably an ideal case, as it will be in sync all the time and can be updated from host with changes reflected in guest. Alternative options may be (1) to allow location to be dynamically specified in limactl start command or (2) have an original template directory mounted in provisioning scripts. In the latter case I can simply copy latest config files in a provisioning script but have to restart an underlying VM.

Alternatives are not ideal but would work better, than asking developer to edit template and point to his project path before creating a vm from a template.

[jandubois]

I really don't understand what the relative filenames would be relative to, and how this wouldn't still be somehow depending on how a developer sets up their environment. I've added some comments in #1351 (comment) about the difficulty of figuring out what base to use to resolve relative pathnames in lima.yaml.

Why not tell the user to set an environment variable (inside lima.yaml) to point to the config file they want to use, e.g.

env:
  MY_CONFIG: ~/.my_config

message: |
  Using config settings from {{.Config.Env.MY_CONFIG}}
  Change the config file by stopping the VM and then run `limactl edit {{.Name}}`

It will be displayed by limactl start:

limactl start myapp.yaml
[...]
INFO[0021] [hostagent] The final requirement 1 of 1 is satisfied
INFO[0021] READY. Run `limactl shell myapp` to open the shell.
INFO[0021] Message from the instance "myapp":
Using config settings from ~/.my_config
Change the config file by stopping the VM and then run `limactl edit myapp`

The variable needs to point to a location that is mounted inside the instance, of course. And unless/until #287 is implemented, the config file content will not be accessible from the provisioning scripts because the mounts haven't happened yet. Well, if you use sshfs; they should exists if you use 9p.

[centur]

@jandubois The idea here was to allow addressing not from user's home directory, but from lima.yaml file's directory

Simple example may clarify this idea:
I have all my projects in ~/projects/ subdir and my colleague uses ~/my-projs/.

If we are working on the same project and want to use one shared lima.yaml file (that we check in into source control), we need to come up with some way to mount our host folders from ~/projects/<proj-foo>/team-configs and from ~/my-projs/<proj-foo>/team-configs
Worst case scenario here is that each of us have to edit their local copy of <proj-foo>/lima.yaml and set it to correct host path for their environment. If we can use some better way (such as . - dot in path would be converted to a current lima.yaml file location at host file system, such as ~/projects/<proj-foo>/lima.yaml for my case and ~/my-projs/<proj-foo>/lima.yaml ) - this would allow us to re-use same lima.yaml in the repo file without editing it.
Any new developer who checks out the same project can safely use limactl start lima.yaml without setting up any paths or environment variables there, that are specific to his environment (such as - at which path he stores the project)

I hope this adds a bit more context to the original description of the suggestion

[jandubois]

The idea here was to allow addressing not from user's home directory, but from lima.yaml file's directory

I assume from the rest of your reply that you are not talking about the $LIMA_HOME/$INSTANCE/lima.yaml file, but the location of the template it was copied from.

As I pointed out in #1351 (comment), this is not always easy. Let's say the instance is started by

$ limactl start https://raw.githubusercontent.com/lima-vm/lima/master/examples/alpine.yaml

What would ../config mean? https://raw.githubusercontent.com/lima-vm/lima/master/config?

And how would we deal with this when the instance is restarted while the host is offline? Do we need to cache the data? Or would the VM fail to restart?

Any mechanism we implement in Lima itself should be generic enough to work meaningfully in all possible configurations.

What I could see supporting would be setting an environment variable in /etc/environment, like

LIMA_TEMPLATE=/usr/local/share/lima/examples/alpine.yaml

Of course the value might be a URL, like

LIMA_TEMPLATE=https://raw.githubusercontent.com/lima-vm/lima/master/examples/alpine.yaml

and then it is up to your tools to figure out what to do with it.

PS: I wouldn't want to hard-code this into Lima either, but provide template expansion for environment variables, and then allow you to do this yourself with something like this:

env:
  LIMA_TEMPLATE: {{.LimaTemplate}}

That way we can make additional useful settings available as additional template variables.

[jandubois]

I'm wondering if what we really want is something like lima-compose with it's own configuration format. Similar to docker-compose it would allow deployment of one or more Lima VMs with more control over their configurations, and how they would be connected to each other.

But I'm not sure if there is wide enough interest in that. Also not clear if this should be part of limactl, or a separate project built on top of Lima.

[centur]

Personally I don't think "docker compose" style would have a good efforts/benefits ratio, it's a massive task but for the (my) simple goal of creating repository-stored lima-based dev environments in yaml files - it's an overkill.

I see what's the problem with using lima with URLs and now I see the point of why it's hard, because it's not always local. Expanding environment variables may work well here, as the local path would not be . or .. but simply some form of ${PWD}var of the process.
PWD might be a fallback value in case of path to a template is a url, not a local file too, but this feels too hacky.

Env vars expansion would work for my case, I assume. Probably it'd be great to have a working example of this specific scenario (I haven't touched my initial "spike" with lima that I did last year when I stumbled over this issue).