Future of Docker releases of python bindings

[fsimonis]

This issue also affects downstream python components.

Problem

With the publication of PEP 668, the pip uses changed.

In short, directly using pip:

• conflicts with the system package manager and can lead to a broken system. A user should use the system package manager to install system-wide packages (apt, pacman, dnf, ..)
• installing with --user interferes with the global python state of a user and can lead to a broken user account.

Proposed solution by the PEP:

• Mark the global system as "externally managed" and block installation for root and --user.
• Direct users to use a venv instead.

Implications on docker releases

To install the preCICE python bindings into an Ubuntu-based docker image one should use Debian packages.

The only pragmatic solution I can think of to make this work with Docker is to use a venv to install the preCICE bindings and then load it on login via /etc/profile.d/.
Problem is that this only works if a user starts a login shell, which isn't the default of docker.

The real solution is probably to drop the Docker releases of python-related packages.
Then always install and install python, and further adapter dependencies in a venv in the CI of whatever needs the bindings.

[BenjaminRodenberg]

The real solution is probably to drop the Docker releases of python-related packages.
Then always install and install python, and further adapter dependencies in a venv in the CI of whatever needs the bindings.

Let's follow this route 👍

I already updated #228 to remove everything related to the docker releases. I think relying on the venvs is the correct approach. A user can also use pip to install from github if the develop version is needed.

[BenjaminRodenberg]

I will close this issue to clean up. @fsimonis feel free to reopen if you disagree.