podman: confusing reference to podman-mac-helper

[colin-arnott-xero]

Describe the bug

podman suggests you use a non-existant binary.

Steps To Reproduce

steps to reproduce the behavior:

[user@localhost:~]$ podman init --now
...

The system helper service is not installed; the default Docker API socket
address can't be used by podman. If you would like to install it run the
following commands:

	sudo /nix/store/yplbfq96nwb894s12ghmwjk618f7q92a-podman-4.3.1/bin/podman-mac-helper install
	podman machine stop default; podman machine start default

...

Expected behavior

should we try and patch out these lines to prevent new user confusion?

Additional context

we could also try and include podman-mac-helper, but it seems like it would make things worse, and the right solution is a nix-darwin module?

Notify maintainers

@marsam @adisbladis @saschagrunert @vdemeester @zowoq

Metadata

Please run nix-shell -p nix-info --run "nix-info -m" and paste the result.

[user@system:~]$ nix-shell -p nix-info --run "nix-info -m"
 - system: `"x86_64-darwin"`
 - host os: `Darwin 22.1.0, macOS 10.16`
 - multi-user?: `yes`
 - sandbox: `yes`
 - version: `nix-env (Nix) 2.11.0`
 - channels(user): `"darwin, home-manager"`
 - channels(root): `"nixpkgs"`
 - nixpkgs: `/nix/store/x070biyjfvlvkf7qpypmfspxzy9a3y3n-source`

[zowoq]

should we try and patch

No. Carrying patches has been discussed previously by the podman maintainers. See #163015 (comment), most of it applies here.

we could also try and include podman-mac-helper

nixpkgs/pkgs/applications/virtualization/podman/default.nix

Lines 51 to 53 in 6c31998

	${if stdenv.isDarwin then ''
	make podman-remote # podman-mac-helper uses FHS paths
	'' else ''

IIRC it still hardcodes /usr/local in places.

but it seems like it would make things worse

Yes, it's the path to the unwrapped binary.

and the right solution is a nix-darwin module?

Yeah guess that would work but fixing it upstream somehow would be better.

[adisbladis]

but it seems like it would make things worse

How would it make things worse? I think we should probably add podman-mac-helper to the output and let a user choose whether to use a nix-darwin module (which I think is better but may not fit everyones workflow) or the builtin helper?

I don't have a darwin machine to test this on right now but would happily accept a PR adding the mac helper util (and make the wrapper aware of it too).

[colin-arnott-xero]

No. Carrying patches has been discussed previously by the podman maintainers. See #163015 (comment), most of it applies here.

I concede your point, and am not pushing back, but this one feels like it is in a different class.

IIRC it still hardcodes /usr/local in places.

yep, it does; see below.

Yes, it's the path to the unwrapped binary.

sure, but even I am unclear exactly how to get it into PATH; non-technical users are going to be lost.

Yeah guess that would work but fixing it upstream somehow would be better.

what would be your proposed upstream fix? I cannot see a clean way for a tool like podman to keep around a launchctl plist that auto-retargets the correct binary in the /nix/store. This seems like binaries containing systemd service definitions.

How would it make things worse? I think we should probably add podman-mac-helper to the output and let a user choose whether to use a nix-darwin module (which I think is better but may not fit everyones workflow) or the builtin helper?

podman-mac-helper does some interesting things during the install, and I think it fundamentally violates expectations about nix and the store. We certainly include other things (say pacman) in the nixpkgs do this too, but I would wager users expect them to do that, where here the fact that podman is pinned to a terrifying old version will cause debugging hell?

[zowoq]

this one feels like it is in a different class.

Yeah, that's fair. If it's just removing those couple of lines I guess we can live with that.

what would be your proposed upstream fix ...

I did have a couple of ideas but can't find were I kept note of them.

TBH after upstream started publishing .pkg installers and the podman-desktop app I didn't really have much hope that they'd be willing to accommodate us. Also means anything we do to hack/patch around it is that much more fraught.

[colin-arnott-xero]

that is quite a shame, but they are likely trying to cater to the docker-desktop crowd.

I am happy to close this out, with a resolution of "we should make home-manager and/or nix-darwin modules", but if there is anything else you maintainers want done to the actual derivation, I am happy to drive that.

[zowoq]

Haven't found my notes but one idea I had was to have the podman binary that was being interacted with by the user (and would presumably be the correct/newer one) check that its own path matched what was listed in the plist. This would likely be a bit noisy as it would alert every time the store path changed, less noisy option could be a version check with the version embedded in the plist, less correct but would avoid getting stuck on an old version.

I've opened a PR to patch out the message.