Migrate images from dockerpy to aiodocker

[mdegat01]

Proposed change

First in a series of PRs to migrate us from Dockerpy to Aiodocker. See #6247 for details and reasoning. This is far too much work for 1 PR so it'll be broken down into chunks.

This PR covers the following:

1. Migrates all usage of dockerpy's ImageCollection object to aiodocker
2. Adds aiodocker to our requirements
3. Initializes both client objects at startup during this migration.
4. The DockerAPI.docker property will now return the aiodocker client object. The DockerAPI.dockerpy property will be used to access the dockerpy client until it is no longer needed

Type of change

• Dependency upgrade
• Bugfix (non-breaking change which fixes an issue)
• New feature (which adds functionality to the supervisor)
• Breaking change (fix/feature causing existing functionality to break)
• Code quality improvements to existing code or addition of tests

Additional information

• This PR fixes or closes issue: fixes #
• This PR is related to issue: Migrate from dockerpy to aiodocker #6247
• Link to documentation pull request:
• Link to cli pull request:
• Link to client library pull request:

Checklist

• The code change is tested and works locally.
• Local tests pass. Your PR cannot be merged unless tests pass
• There is no commented out code in this PR.
• I have followed the development checklist
• The code has been formatted using Ruff (ruff format supervisor tests)
• Tests have been added to verify that the new code works.

If API endpoints or add-on configuration are added/changed:

• Documentation added/updated for developers.home-assistant.io
• CLI updated (if necessary)
• Client library updated (if necessary)

[mdegat01]

Looking at the failed build log, I'm thinking that the idea of doing this migration in stages may not work right now. Both libraries want the same unix socket and I don't think it can work like that. We may actually have to do this as one giant PR unless we can find a way to get both running simultaneously during the migration

[mdegat01]

Ok I resolved the conflict with the unix sockets. In testing locally it seems to work fine as long as you aren't using literally the same file. So by binding one to /run/docker.sock and the other to /var/run/docker.sock things seem to work fine.

[agners]

Ok I resolved the conflict with the unix sockets. In testing locally it seems to work fine as long as you aren't using literally the same file. So by binding one to /run/docker.sock and the other to /var/run/docker.sock things seem to work fine.

To me this doesn't really make sense, since the two sockets are symlinked, so these end up to be the same files. Also, I would expect that the two libraries open a separate file handle, which should not cause any interference.

I tried to reproduce that by using /run/docker.sock for both libraries locally, and it did not seem to cause an issue.

Afaik, these were the two problematic "Run the Supervisor" CI runs:

• https://github.com/home-assistant/supervisor/actions/runs/18538493066/job/52840267827
• https://github.com/home-assistant/supervisor/actions/runs/18541341771/job/52928360530

I've reverted the change again, but this time the run went though fine

• https://github.com/home-assistant/supervisor/actions/runs/19238700199/job/54995906263?pr=6252

I did run the CI run a couple of times, it worked every time. So, its not reproducible anymore!? 🤔 😕 Maybe something was wrong with GitHub back then?

[agners]

This makes Docker interactions of Supervisor using asyncio patterns 🤩! Just a minor nit, other than that, PR looks great! I also like the change to fire_event to return tasks and actually await them 👍.

[home-assistant]

Please take a look at the requested changes, and use the Ready for review button when you are done, thanks 👍

Learn more about our pull request process.