feat: use docker-compose library, download docker-buildx, fixes #7915

[stasadev]

The Issue

• Fixes Future strategy for Docker Compose (binary vs library) and Docker Buildx #7915

Related:

• DDEV no longer can detect plugins on NixOS #8183

How This PR Solves The Issue

We added a requirement for docker-buildx in:

• feat: add Docker buildx plugin as hard requirement, fixes #8117 #8149

Docker Compose has required this since v2.40.2, but the requirement was only triggered when installing extra packages or using EOL PHP versions like 7.4. Most users never hit this problem.

However, some users have trouble configuring Docker Buildx, likely because the setup steps are not always read carefully.

---

This PR uses the Docker Compose SDK to download docker-buildx to $HOME/.ddev/bin/docker-buildx, and updates cliPluginsExtraDirs to include $HOME/.ddev/bin in docker_manager.go.

cliPluginsExtraDirs works here only because we use the Docker Compose SDK. The standalone docker-compose binary does not recognize it.

This allows the code to find docker-buildx in the expected location and removes the need for a bundled docker-compose.

Manual Testing Instructions

Automated Testing Overview

Release/Deployment Notes

[github-actions]

Download the artifacts for this pull request:

• ddev-windows-arm64-installer.zip
• ddev-windows-arm64.zip
• ddev-windows-amd64-installer.zip
• ddev-windows-amd64.zip
• ddev-linux-amd64.zip
• ddev-linux-arm64.zip
• ddev-macos-arm64.zip
• ddev-macos-amd64.zip
• all-ddev-executables.zip

See Testing a PR.

[rfay]

Rebased, trivial merge conflict.

[rfay]

I imagine I shouldn't have mucked with this, I only intended a rebase. But since I did rebase it, and since you can back out both the rebase and the fix, here's the analysis of the breakage.

• Rebased against upstream/main
• Picked up latest docker/cli 29.3.0, which didn't work with stuff here
• Did go fix to use maps.Copy that make staticrequired complained about.

Build breakage from docker/cli v29.3.0

After the rebase onto upstream/main, the build broke with:

vendor/github.com/docker/cli/cli/command/container/tty.go:63:23:
cannot range over 10 (untyped int constant): requires go1.22 or later
(-lang was set to go1.16; check go.mod)

Root cause: github.com/docker/cli uses CalVer and deliberately has no go.mod (only a vendor.mod), because they use CalVer rather than SemVer and don't want Go module semantics. This means it is pulled in as +incompatible, and Go defaults to go1.16 language semantics when compiling vendored code from it — regardless of what the main module's go directive says.

v29.3.0 (pulled in by the deps update in #8198) introduced for retry := range 10 (go1.22 range-over-integer syntax) in tty.go. With go1.16 semantics enforced by the missing go.mod, this is a compile error.

This is a known recurring issue in docker/cli: docker/cli#6852. The maintainers have described it as "whack-a-mole" until they adopt a proper go.mod.

Fix applied: Pinned docker/cli back to v29.2.1, which is also the version docker/compose/v5 itself declares as its minimum. See commit 7cd22c8.

Going forward: When bumping docker/cli, keep it pinned to the version that docker/compose/v5 requires — let compose drive it upward, since compose has a proper go.mod and will only declare a docker/cli version it can actually compile against.

Re CI: This should have been caught by CI before the rebase landed in upstream/main via #8198. Worth checking why the build job did not fail there.