Thanks for the heads up.

It's worth noting for others that (it appears from a quick read, I haven't actually used this yet), the compromise for gaining the "docker-compose" superpower is that you will have to run a podman service (Daemon). This comes counter to some (not all) of the benefits I mentioned above, but is a necessary compromise if one wants the power of compose style orchestration; that is, that there must be some deamon to manage it.

This is not authoritative, I may be mistaken, but this is my educated guess based on a quick read and my knowledge of Docker et al.

The Podman daemon can run as a user service, so the only advantage that would be lost is not having to run a daemon at all (but I don’t think one can avoid that if Docker API compatibility is needed). Is there something else I’m not considering?

No Daemon at all is what I was alluding to. A smaller memory footprint and lower attack surface are advantages of that, it may not be an issue for many/most but is worth pointing out I hope.

I've had mixed results with that. Sometimes it works flawlessly, sometimes it doesn't.

It should be said that I was mixing that with non-root podman (although that should be a supported usage).

I went back to podman-compose.

Dunno