Closed stephanierifai closed 6 months ago
Where does this new package install the compose binary?
~ # dpkg -L docker-compose-plugin
/.
/usr
/usr/libexec
/usr/libexec/docker
/usr/libexec/docker/cli-plugins
/usr/libexec/docker/cli-plugins/docker-compose
/usr/share
/usr/share/doc
/usr/share/doc/docker-compose-plugin
/usr/share/doc/docker-compose-plugin/changelog.Debian.gz
Hi, today I noticed "Use Docker Compose V2" had been checked in Docker Desktop settings without me doing it (I specifically disabled it before as we use Lagoon and Compose V2 is not supported yet). Not sure why this happened? Is it because V1 has reached end of life on the 28th of March?
I can understand you want to push for v2 now but changing settings automatically without any warning is very surprising and dangerous.
Hi @uandco, sorry that happened to you, I agree that you shouldn't get opted back in after opting out in the past, i'll check with the team what might have happened. We're planning to go to GA soon and then will evaluate a plan for end of life of V1 following the feedback from GA. I kept those dates in just for history, but we far long ago ditched that timeline based on the feedback of making sure linux had an easy install path before we marked v2 GA!
Hi all! I have updated the proposal due to Compose V2 GA announcement. Looking forward to your feedback!
In that case there is not even a way to have a .env file that a) contains a $ in a value, and b) is compatible with both V1 and V2
This is not 100% correct. I commented a workaround here docker/compose#8763 (comment) this will allow you to use
$
but it won't be evaluated.
Nope, the behavior with single quotes around the value in docker compose V1 is platform-dependent:
If anything changes with respect to quotes or other escape character processing when reading .env files in compose V2, then this needs to be announced loudly (and correctly) in the migration docs.
https://github.com/compose-spec/compose-spec/blob/master/spec.md sounds like the behavior of compose V2 matches V1 on Linux. That would be great!
I just noticed the April 2023 date on
Users can no longer opt-out of V2 via the Docker Desktop UI or through the docker-compose disable-v2 command in new versions
I think this needs pushed out a while because compose V2 as released does not work for building large compose projects @ndeloof just put in a fix https://github.com/docker/compose/issues/9091 that if I am reading correctly is tagged for 2.15.0 and according to the documentation https://docs.docker.com/compose/install/ for windows we need to wait for Docker Desktop to incorporate the change. Given what seems to be a monthly release cycle, we may be able to get it by late Jan. and time to get it into our build environments it is likely mid Feb. leaving only a month and a half to actually verify the fix works before there is no way to disable V2 on windows. (Linux simlink's don't generally work well in windows). Also the default buildkit builder in Docker desktop is not configurable https://github.com/moby/buildkit/issues/2906 making the issues with parallel builds worse. Our system setup is to install docker and disable compose v2 and given the number of issues you find on the web/github related to parallel builds where the solution provided is not possible in windows (due to the above issues).
I propose extending the date out 3-6 months and possibly adding a notice inside the Desktop GUI that V1 will be removed in an upcoming release. To encourage those of us with large systems to give compose V2 another try, as we have been burned for a while. like the comment here https://github.com/docker/compose/issues/9091#issuecomment-1099388054 from @WolfspiritM
... I made a buildx issue 2 years ago: https://github.com/docker/buildx/issues/359 There is no flag to specify how many parallel jobs are run...there is no flag to specify memory and cpu... Are we the only ones using docker-compose with more then just a simple TODO App?
Due to MAC + VPN + DNS issues in Go prior to 1.20 our user base is required to use docker-compose v1 in order to use the Python dns resolution paths instead of the Go based ones. Removing the ability to opt out of v2 should be gated by getting a release of Docker Desktop that is built with Go 1.20 or later.
@draco2003 latest Docker Compose v2.16.0 release is built with Go 1.20, see changelog
I can confirm v2.16.0 resolves the MAC + DNS + VPN issue! 🍾 Looking forward to seeing it come with Docker Desktop and resolve a ton of our support issues!
@stephanierifai I believe that we can close this issue
@hyu please close this issue as completed
This issue is now closed, as Docker Compose v1 has been deprecated as of July 2023. More details in our docs page, "Migrate to Compose V2".
Tell us about your request End maintenance of Docker Compose v1
Which service(s) is this request for? Dev-tools
Tell us about the problem you're trying to solve. What are you trying to do, and why is it hard? The goal of compose v2 was to align on Go for most of our development. In order to focus our time towards new features and enhancements, we need to make v2 the default and phase out v1.
Are you currently working around the issue? N/A
Additional context On April 26, 2022, we announced the GA of Docker Compose V2. We want you to have ample time to transition to Compose V2. We won’t sunset Docker Compose V1 immediately, and developers can still revert to V1. Given the numerous successful transitions to Compose V2 so far, we’ve created the following proposed timeline for Docker Compose V1's end of life (EOL):
October 2022 - 6 Months Post GA
docker-compose
todocker compose
docker-compose disable-v2
commandApril 2023 - 1 Year Post GA
docker-compose
todocker compose
docker-compose disable-v2
command in new versionsNote: We have no plans of removing any aliasing of
docker-compose
todocker compose
, we want to make it as easy as possible to switch and not break any of your code.We’ll monitor feedback here alongside V2’s usage and make adjustments accordingly.