Prior compose install not showing correctly in CLI Tools

containers / podman-desktop

Podman Desktop - A graphical tool for developing on containers and Kubernetes

https://podman-desktop.io

Apache License 2.0

4.35k stars 276 forks source link

Prior compose install not showing correctly in CLI Tools #5250

Open deboer-tim opened 6 months ago

deboer-tim commented 6 months ago

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

benoitf commented 6 months ago

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

deboer-tim commented 6 months ago

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.

francoism90 commented 6 months ago

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.

benoitf commented 6 months ago

@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

francoism90 commented 6 months ago

@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 commented 6 months ago

hmm ok it searches for docker-compose

francoism90 commented 6 months ago

@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?

benoitf commented 6 months ago

@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

benoitf commented 6 months ago

it will fetch docker-compose binary and then you'll be able to do podman compose

francoism90 commented 6 months ago

@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.

benoitf commented 6 months ago

@francoism90 sure

carwyn commented 2 months ago

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.

rnnr commented 2 months ago

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?

odockal commented 1 month ago

I believe we can handle this one issue since it was resolved for kubectl already.

axel7083 commented 1 week ago

@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 ?

axel7083 commented 5 days ago

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