MacOS Support Meta-Issue

[tomeichlersmith]

This issue is focused on discussion and notes related to supporting MacOS. Related issues that hold some history on this topic are

• 102

• 71

• 80

---

Containers are an inherently Linux technology. The only way containers are spawned on non-Linux operating systems like MacOS and Windoze is via a Linux VM. On Windoze, docker instructes installers to use WSL which is helpful for us because that encourages the user to directly interact with a Linux shell hosting the containers. This makes Windoze "support" rather natural - just use the tightly-integrated WSL VM and you are good to go.

The MacOS ecosystem is a bit more complicated. From what I can tell, there are two main "camps". For our purposes, the Lima route seems preferable since, like WSL, the "middle layer" of the Linux VM is exposed to the user. However, the Docker on Mac route is already embraced by many of the users I'm developing this program for and may exist for a long time. With this in mind, I'd like to at least understand how to support some subset of the denv abilities for this route.

Docker on Mac

Docker on Mac (DoM) enables docker by launching VMs under-the-hood (I presume), but understanding this technology is a bit complicated since it is proprietary (as far as I can tell).

• [ ] UID: From #102 I suspect that the VM DoM is launching pre-maps the host user to root in the guest Linux VM. This makes denv's goal of mapping the host user into the container itself impossible since that information is already lost by the time execution gets to denv. Nevertheless, we could support most of the other abilities of denv since prior work with DoM in ldmx-sw makes it seem like the files written by processes within the container are still given ownership to the user outside of the container (and outside the VM).
• [x] GUI: From prior experience with ldmx-sw, we probably need to define some DISPLAY variable like docker.for.mac.host.internal so that the docker CLI knows to connect the GUI display between the container and the VM and the VM and the host. #120

Lima

Launch tightly-integrated Linux VMs via lima and then run whatever container runner you want (they have apptainer, podman, docker, and nerdctl templates already). With daemon-based runners like docker, you can even have the "client" CLI be outside the VM and redirected to the "host" daemon inside the VM so it appears native. There is even another package colima which acts like the daemon directly. I suspect that Docker on Mac does something similar.

• [x] Basics: Is running lima denv ... functionally equivalent to running denv on a Linux host? If so, then we could move support via this route to a question of maintaining a Lima VM config (or a set of tips) to help make denv more useful.
• [ ] UID: How does the user information look on these VMs? Are they the same as the host?
• [ ] GUI: Is launching GUI applications from these VMS supported? What about from a container inside these VMs?
• [ ] From the initial testing https://github.com/tomeichlersmith/denv/issues/71#issuecomment-2032368647, it looks like some paths are re-mapped inside the VMs (or some prefix is added). Is there a way to avoid this? Can I have denv control which mounts are made with the VM or would I need to document the config-changes necessary to add additional (non-home) mounts?
  • For example, it looks like the only mounts between the host and guest VM in the docker template of lima is the home directory ~ (read only) and /tmp/lima. They do make it pretty simple to opt-in to allowing writing to home directory which is probably what we want for our purposes.

[tomeichlersmith]

The basic lima denv ... seems to run as expected. The only failing test is checking the group id. And I'm unsure at the moment if the groupid is only mismatched between container and VM since I'm running the entire testing suite inside the lima VM.

Full Test Output Log

Installed lima v0.22.0 and `brew install qemu` on macos-13. Ran ``` $ limactl start \ --name=default \ --mount-writable \ template://docker $ lima TMPDIR=/tmp/lima ./ci/test docker INFO: Testing denv with 'docker' 1..35 ok 1 print version of denv ok 2 print check help ok 3 print config ok 4 change image being used ok 5 add a new mount ok 6 change shell program ok 7 disable network connection ok 8 basic check run ok 9 quiet check run ok 10 check fails when using unsupported runner ok 11 check that we are in a workspace ok 12 check that we are not in a workspace ok 13 denv name available in denv ok 14 we can share host environment variables ok 15 we can prevent sharing of host env vars ok 16 we can copy specific env vars ok 17 we can set (and override) env vars ok 18 pass exit code onto caller ok 19 call a simple executable non-interactively ok 20 by-pass broken .bashrc if non-interactive ok 21 no init denv should fail ok 22 can print denv help without a denv ok 23 can print denv init help without a denv ok 24 can print denv config help without a denv ok 25 can print denv config env help without a denv ok 26 denv can init ok 27 denv should not init twice ok 28 we can connect a socket to a Google public DNS server ok 29 we can disable network devices ok 30 whoami matches inside and outside denv not ok 31 file created inside denv has id match # tags: macos # (from function `assert_equal' in file test/test_helper/bats-assert/src/assert_equal.bash, line 40, # in test file test/ownership.bats, line 32) # `assert_equal "$(cat file-from-denv-ownership)" "$(id -u ${USER}):$(id -g ${USER})"' failed # # -- values do not equal -- # expected : 501:1000 # actual : 501:0 # -- # ok 32 run minimal shebang requiring readable workspace ok 33 pass arguments to the script ok 34 shebang with neither requirements met errors out ok 35 minimal shebang without readable workspace ```