Closed synweap15 closed 1 year ago
Hi,
What distro and CPU architecture are you using? Also how did you install Python? This failure looks like PyYAML
isn't able to be compiled and there's no wheel available to avoid compiling dependencies.
But yes, separate to that defaulting to v2 would be a good idea.
Hello @nickjj,
It's a droplet on DigitalOcean.
Distro: Ubuntu 22.04.2 LTS Arch: x86_64
Python preinstalled with version 3.10, installed 3.11 with ppa:deadsnakes
as an alternative.
Indeed, PyYAML
seems to be to blame here, but since Docker Compose v1 is no longer maintained, there does not seem to be a sane way to continue supporting the old release.
Thank you @nickjj!
Version v2.3.0 no longer installs Docker Compose v1 by default. That's available to install from the Galaxy.
As for your issue with PyYAML, I'm not able to reproduce it on a system that has python3 installed. I tried a bunch of assorted Ubuntu and Debian releases on multiple cloud providers and a vanilla Ubuntu ISO. It worked in every case.
You can reproduce this issue on Ubuntu 24.04
with Python 3.12
. Since upgrading the docker-compose version isn't feasible within a day, you will need to use version 1.29.2
. This is the final Compose V1 release, dated May 10, 2021
, and it has not received any security updates since. Proceed with caution.
Manual intervention is required; otherwise, the role may need to be updated.
To resolve the issue, execute the following commands on the remote machine:
# Install the Python 3.12 virtual environment package
apt install python3.12-venv
# Create a virtual environment
python3 -m venv /usr/local/lib/docker/virtualenv
# Activate the virtual environment
source /usr/local/lib/docker/virtualenv/bin/activate
# Install pyyaml version 5.3.1
pip3 install -U pyyaml==5.3.1
By performing these steps, you can install pyyaml
version 5.3.1
within the virtual environment. Docker Compose V1 (docker-compose 1.29.2) requires at least pyyaml
version 5.3.1
. Resolving this dependency manually will fix the Docker Compose installation process.
TASK [nickjj.docker : Symlink selected Python package binaries to /usr/local/bin] **************************************************************
skipping: [bot-01] => (item={'name': 'docker', 'state': 'present'})
skipping: [bot-02] => (item={'name': 'docker', 'state': 'present'})
skipping: [bot-03] => (item={'name': 'docker', 'state': 'present'})
changed: [bot-02] => (item={'name': 'docker-compose', 'version': '1.29.2', 'path': '/usr/local/bin/docker-compose', 'src': '/usr/local/lib/docker/virtualenv/bin/docker-compose', 'state': 'present'})
changed: [bot-01] => (item={'name': 'docker-compose', 'version': '1.29.2', 'path': '/usr/local/bin/docker-compose', 'src': '/usr/local/lib/docker/virtualenv/bin/docker-compose', 'state': 'present'})
changed: [bot-03] => (item={'name': 'docker-compose', 'version': '1.29.2', 'path': '/usr/local/bin/docker-compose', 'src': '/usr/local/lib/docker/virtualenv/bin/docker-compose', 'state': 'present'})
@nickjj
Is the issue here that pyyaml needs to be locked to 5.3.1? This role already sets up a virtual environment.
Is the issue here that pyyaml needs to be locked to 5.3.1? This role already sets up a virtual environment.
Essentially, yes. Seems like it's either 1) don't install Docker Compose v1 (which is the role's default behaviour) or 2) lock pyyaml to 5.3.1.
The role supports defining docker__pip_packages: []
, you could do something like this:
docker__pip_packages:
- name: "pyyaml"
version: "5.3.1"
It's not ideal, but if we really wanted to continue supporting Docker Compose v1 that could be moved to docker__default_pip_packages
so it's installed by default but only if Docker Compose v1 is enabled. I'm not sure if it's worth optimizing or complicating the role to support something that has been deprecated for 3+ years.
The role supports defining docker__pip_packages: []...
That is exactly what we've been doing at our place for several weeks now. Indeed, it would have been nice to have pyyaml 5.3.1 locked.
We transitioned to Docker Compose v2 a couple months ago (but left DCv1 for compatibility), so now it looks like the best course of action is to make the last push and remove DCv1 and docker__pip_packages
workarounds. Thus, I have no say on how to make this palatable for those who would like to continue using DCv1.
Yep, I would suggest removing v1 at this point if everything is confirmed to be working with v2. If other issues like this pop up for others we can consider adding it by default but for now maybe it's worth sticking with it as is.
pip install docker-compose
causes an error when running on a fresh build Python 3.10, Python 3.11. Docker Compose V1 is no longer maintained as of July 2023: https://docs.docker.com/compose/More info: https://stackoverflow.com/questions/76868274/build-failed-with-aws-ebcli-on-python-3-11-4
For this role, settings
docker__pip_docker_compose_state: "absent"
solves it, and I think it should be the default?Thanks @nickjj for a great plugin!