When ktd is invoked, it used to call docker-compose command from the current PATH. This causes conflict with newer versions of docker which install their own version of docker-compose in the PATH. The version from Docker is using the "Compose V2" standard which is not yet supported by kubetools (WIP: #163).
This change makes sure that we call the "python" version of docker-compose. By using the current "executable", i.e. the current interpreter which is running ktd, and calling compose as a Python module, we maximise the chances that the version of docker-compose used is the Python one that was installed as a dependency of kubetools.
This creates the opportunity to install kubetools in its own separate virtualenv and run it by linking kubetools and ktd executables into the PATH. In a similar fashion, this should allow the support of pipx as an installation method.
gchazot
commented
6 months ago
Purpose of PR
When
ktdis invoked, it used to calldocker-composecommand from the current PATH. This causes conflict with newer versions of docker which install their own version ofdocker-composein the PATH. The version from Docker is using the "Compose V2" standard which is not yet supported bykubetools(WIP: #163).This change makes sure that we call the "python" version of
docker-compose. By using the current "executable", i.e. the current interpreter which is runningktd, and callingcomposeas a Python module, we maximise the chances that the version of docker-compose used is the Python one that was installed as a dependency ofkubetools.This creates the opportunity to install
kubetoolsin its own separate virtualenv and run it by linkingkubetoolsandktdexecutables into the PATH. In a similar fashion, this should allow the support ofpipxas an installation method.