podman-desktop
podman-desktop copied to clipboard
containers
Prior compose install not showing correctly in CLI Tools
Bug description
The same problem as #5216 appears to exist for compose as well.
I have docker-compose installed at /usr/local/bin/docker-compose and it works with podman compose, but we are unable to detect it/the version in CLI Tools:
Operating system
macOS 14.1
Installation Method
None
Version
1.6.0
Steps to reproduce
No response
Relevant log output
No response
Additional context
No response
I think this one is not critical as most of people don't install docker-compose CLI (like kubectl) but they install usually 'docker desktop' that brings docker compose
Confirming I'm ok with this: users are far more likely to have existing kubectl install vs docker-compose. We should fix, but not release-blocking.
Is this related? I'm running Fedora Silverblue with podman-compose as overlayed package, however it doesn't work in Podman Desktop.
It works perfectly fine in the terminal.
@francoism90 how did you installed Podman Desktop, with flatpak ?
maybe it's related to flatpak sandboxed env.
could you try with a "binary/expanded directory"
https://github.com/containers/podman-desktop/releases/download/v1.6.3/podman-desktop-1.6.3.tar.gz
@benoitf I'm indeed using the Flatpak app.
It's the same for bin, it cannot find podman-compose:
$ which podman-compose
/usr/bin/podman-compose
I just installed podman-compose, not podman-docker, etc.
Hmm, does it search for docker-compose? Because I don't have that file.
@benoitf Yes, but it doesn't seem to be included:
https://packages.fedoraproject.org/pkgs/podman/podman-docker/fedora-rawhide.html#files
Maybe docker compose?
@francoism90 if you go to settings then resources page there is compose, then click on the setup/onboarding icon on the left of compose card, it should download it for you, etc
it will fetch docker-compose binary and then you'll be able to do podman compose
@benoitf This seems to work:
sudo ln -s /usr/bin/podman-compose /usr/local/bin/docker-compose
But I don't think it's recommended, lol. Wouldn't docker compose work? Because it does work, after installing podman-docker.
Hmm, I would prefer the packaged version, over installing binaries using a command.
There are new docker packages, which include docker-compose here:
https://copr.fedorainfracloud.org/coprs/gotmax23/docker-ng/
By including docker-compose-switch in the packages installed it has created a \usr\bin\docker-compose shim that calls docker compose
Not sure if this all works yet, but there does seem to be an effort to get up to date docker-compose packaged and able to interact with podman.
It would be much better to pull in all dependencies for podman-desktop in via packages than installing things under /usr/local.
I had to symlink /usr/libexec/docker/cli-plugins/docker-compose to /ust/local/bin so Podman Desktop finds it - what about adding an option to enter the paths manually too, or give it its own bin directory?
I believe we can handle this one issue since it was resolved for kubectl already.
@deboer-tim @benoitf @jeffmaury what is the expected behaviour if we have an older version (let's say 2.26.0) installed system wide on the user PATH, and we do detect it, and wants to update it.
Do we
- delete the existing version, and install the new one system wide ?
- replace the existing version with the new one
- install the new one in the extension folder, and keep the system wide installed ?
What if we try to install a new one and we already have one installed system wide ?
Following discussion in standup, the expected behaviour is the following.
If the docker-compose is available system wide in a path that would not be the one where podman-desktop would place it system-wide, then it will show an error/warning modal when the user try to update it, cancelling the update.
Otherwise, if the exe is available in the path the extension would place the executable system wide, it simply proceed in the same way it would have done if it owned the executable