docker-desktop: remove docker-compose linking

[DexM]

This symlink is broken and it seems it's unnecessary at all.

Docker Desktop will create symlinks for CLI plugins on the first run, so this manual step seems unnecessary. On my machine, it created a symlink to docker-compose in ~/.docker/cli-plugins/docker-compose anyways. And if I run docker info I see that Docker loads all CLI plugins from ~/.docker/cli-plugins and does not use /usr/local/cli-plugins/docker-compose.

Also, according to Docker Compose CLI plugin manual installation instructions it should be placed in /usr/local/lib/docker/cli-plugins and not /usr/local/cli-plugins.

I'm also not sure whether all the other symlinks created by this Cask in /usr/local/bin are necessary. Because even when they exist, Docker Desktop will still ask the user where to install CLI binaries. This functionality exists in Docker Desktop for a while already, so I think it's safe to simplify this Cask to just copying Docker.app. That way it won't need sudo. Also, Docker Desktop can install all the binaries it needs in ~/.docker/bin, so it's possible to install Docker Desktop without sudo at all, but this Cask forces global binaries. Don't know whether it's by design, or just a legacy.

---

After making any changes to a cask, existing or new, verify:

• The submission is for a stable version or documented exception.
• brew audit --cask --online <cask> is error-free.
• brew style --fix <cask> reports no offenses.

Additionally, if adding a new cask:

• Named the cask according to the token reference.
• Checked the cask was not already refused (add your cask's name to the end of the search field).
• brew audit --cask --new <cask> worked successfully.
• HOMEBREW_NO_INSTALL_FROM_API=1 brew install --cask <cask> worked successfully.
• brew uninstall --cask <cask> worked successfully.

---

• AI was used to generate or assist with generating this PR. Please specify below how you used AI to help you, and what steps you have taken to manually verify the changes, including zap stanza paths.

---

[Copilot]

Pull request overview

Removes the Homebrew Cask-managed symlink that linked Docker Desktop’s bundled docker-compose CLI plugin into /usr/local/cli-plugins, aligning the cask with Docker Desktop’s own CLI plugin installation behavior and avoiding use of a nonstandard plugin directory.

Changes:

• Remove the binary stanza that linked Docker.app/Contents/Resources/cli-plugins/docker-compose to /usr/local/cli-plugins/docker-compose.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[bevanjkay]

Also, according to Docker Compose CLI plugin manual installation instructions it should be placed in /usr/local/lib/docker/cli-plugins and not /usr/local/cli-plugins.

In that case, wouldn't the correct fix be to update the directory to be the correct one?

[DexM]

In that case, wouldn't the correct fix be to update the directory to be the correct one?

I don't know why Homebrew should even bother managing those symlinks. If it was up to me I'd leave it all to Docker Desktop itself :) Currently Docker Desktop installs 15 CLI plugin symlinks in ~/.docker/cli-plugins folder, docker-compose is just one of them. Not only that, but it also tracks this folder and recreates missing symlinks if they get deleted. Sure, this functionality can be turned off, but at that point it's probably user's prerogative to do whatever they want. Not sure what use case does Homebrew solve by installing this symlink.

Same goes for /usr/local/bin folder. Here's what I get when I install Docker Desktop manually (downloading and manually copying Docker.app to /Applications, no Homebrew):

cagent -> /Applications/Docker.app/Contents/Resources/bin/cagent
docker -> /Applications/Docker.app/Contents/Resources/bin/docker
docker-compose -> /Applications/Docker.app/Contents/Resources/cli-plugins/docker-compose
docker-credential-desktop -> /Applications/Docker.app/Contents/Resources/bin/docker-credential-desktop
docker-credential-osxkeychain -> /Applications/Docker.app/Contents/Resources/bin/docker-credential-osxkeychain
kubectl -> /Applications/Docker.app/Contents/Resources/bin/kubectl
kubectl.docker -> /Applications/Docker.app/Contents/Resources/bin/kubectl

This list is slightly different from the one in this Cask. I don't know whether it's intentional, so I didn't touch it. But again, I'd probably just leave it to Docker devs to manage that :)

[bevanjkay]

From my understanding, there's two reasons;

1. It copies the behaviour of the Docker commandline installer, that creates the symlinks - https://docs.docker.com/desktop/setup/install/mac-install/#install-from-the-command-line
2. It makes the binaries available in the users $PATH by default.