Docker-compose seems broken on Kyria

I'm running

System:    Kernel: 5.4.23-1-MANJARO x86_64 bits: 64 compiler: gcc v: 9.2.1 Desktop: Gnome 3.34.4 
           Distro: Manjaro Linux 

When I install docker-compose build (or most other commands other than help) there seems to be a conflict between dependencies. Notably, doing a docker-compose buildtriggers a python stack trace:

$ docker-compose images
Traceback (most recent call last):
  File "/bin/docker-compose", line 11, in <module>
    load_entry_point('docker-compose==1.25.4', 'console_scripts', 'docker-compose')()
  File "/usr/lib/python3.8/site-packages/compose/cli/", line 72, in main
  File "/usr/lib/python3.8/site-packages/compose/cli/", line 125, in perform_command
    project = project_from_options('.', options)
  File "/usr/lib/python3.8/site-packages/compose/cli/", line 54, in project_from_options
    return get_project(
  File "/usr/lib/python3.8/site-packages/compose/cli/", line 147, in get_project
    client = get_client(
  File "/usr/lib/python3.8/site-packages/compose/cli/", line 118, in get_client
    client = docker_client(
  File "/usr/lib/python3.8/site-packages/compose/cli/", line 127, in docker_client
    client = APIClient(**kwargs)
  File "/usr/lib/python3.8/site-packages/docker/api/", line 127, in __init__
    self._auth_configs = auth.load_config(
TypeError: load_config() got an unexpected keyword argument 'config_dict'

The offending call is trunicated above, but it is:
File "/usr/lib/python3.8/site-packages/docker/api/", line 127, in init

self._auth_configs = auth.load_config(
            config_dict=self._general_configs, credstore_env=credstore_env,

At that point of execution, auth is a package loaded into the namespace via from .. import auth which loads: /usr/lib/python3.8/site-packages/docker/auth/
Which defines the function that is being called in the traceback:

def load_config(config_path=None):

Which in fact does not have the config_dict that the api/client code is attempting to pass it.

My relevant packages:

$ pamac list | grep docker
docker                                   1:19.03.6-1                 community  190.9 MB
docker-compose                           1.25.4-1                    community  1.3 MB
python-docker                            4.2.0-1                     community  1.4 MB
python-docker-pycreds                    0.4.0-5                     community  19.7 kB
python-dockerpty                         0.4.1-6                     community  85.8 kB

I eventually got docker-compose working by loading the binary from the authoritative upstream (per which solved my immediate need (and confirms that my own docker compose file and operating environment isn't at fault). It'd obviously be nice to have this as a functional managed package though.

This is a Python specific error in the application - talk the upstream packager.

HINT: They are not Manjaro packages.

Thanks for the reply @linux-aarhus. I'm relatively new (< 1yr) with manjaro and I'm not entirely sure how the community repository is managed. I see with pamac info docker-compose that there is a Packager listed by email. Is that the recommended method of reporting errors in the packages? Is there an issue tracker somewhere I should use, or just count on email getting seen and acted upon? Is there a way to initiate a pull request against a public repo of the package?

The community repository is for the main part and the majority of packages is a copy the Arch community repository with the addition of some AUR packages which will be packaged and maintained by a Manjaro team member (recognized by their email).

Manjaro has no issue tracker for non-Manjaro packages - the issue tracker for Manjaro specific apps is found at - for non-Manjaro packages we really can't do anything - but refer them upstream.

Before you report any issues upstream it is advised that you recreate the issue using an Arch installation - inconvenient - yes - but that is how it is.

All other packages are packaged by Arch Trusted Users. Those users they may or may not respond positive - even though it is an Arch package. Very often the response is - Manjaro system - ask Manjaro - and such response is - in my opinion - less than desirable - but let that be.

I cannot help you with such reproduction as I don't know or use docker.

I use docker-compose with manjaro stable (same versions as you) and archlinux stable all days - no problem ! it's your config ???

We can found same (old) error in web "docker-compose TypeError: load_config() got an unexpected keyword argument 'config_dict'"

@papajoke: I'm pretty sure it's NOT my config. I literally pointed out the source code where the bug/discrepancy exists (docker library being called by docker-compose with a parameter that isn't defined in the function spec of the API). As I stated in the last paragraph of the post that started this discussion, I also installed the latest docker-compose binary straight from the docker github and it runs just fine in my environment. The issue appears to be a version mismatch between docker and docker-compose. Would you mind sharing the output of pamac list | grep docker so I can see what versions of these libraries are working for you?


pacman -Q | grep docker
docker 1:19.03.6-1
docker-compose 1.25.4-1
python-docker 4.2.0-1
python-docker-pycreds 0.4.0-5
python-dockerpty 0.4.1-6

when we read link found with this error (2018 and 2019), generally is python not docker (pyenv ?)

Ok, so I wasn't sure what you were asking here, as Python is clearly not docker. I wasn't running the application in any special python environment (no pyenv, no virtualenv, etc). However, you asking about python and pyenv did prompt me to shift my attention from looking at just what pamac was showing as installed and pushed me to investigating what python is reporting as installed. I was surprised to see both 'docker' and 'docker-py' were both installed. Even after removing all docker utilities installed via the Manjaro package management, I noticed that pip freeze | grep docker showed docker-py and xonsh-docker-tabcomplete were both still installed. Removing those packages (using the underlying python package management), I was able to do fresh installations of docker and docker-compose using pamac and things seem to be working. So, although I'm not 100% what question you were trying to ask, it totally led me to solving my problem. Seems the problem was environmental after all. Apparently, the docker-compose I loaded from github following the instructions on is a "compiled" version that includes it's own packaged version of python and required libraries, so it wasn't affected by the errant 3rd party installation of the incompatible docker-py library. Thank you for pointing me in the right direction!

-- William

1 Like

This topic was automatically closed 180 days after the last reply. New replies are no longer allowed.

Forum kindly sponsored by