Duplicate of #1003

and remove unneeded installation of python3-pip.

Why?

Why?

Because it is unneeded as the commit message says? It was (re-)added in commit f1527a2 without giving a reason.

PR (and commit message) updated to fix conflict with preceding PR.

Because it is unneeded as the commit message says?

It says:

Remove unneeded installation of python3-pip

That's not an explanation. Why are we investing so much time to remove a tiny package that is usually needed (except with the python -m pip workaround)?

It was (re-)added in commit f1527a2 without giving a reason.

IMO the burden for an explanation is still on your side (even if it had been removed earlier).

This did create a regression – see new CI failure.

So even if I can see your argument that in Docker we want /usr/local as venv and therefore must avoid conflict with /usr – that now necessitates doing your python3 -m pip trick in in core as well.

😆 OK, that was a long way to to go to get back to where we were before we started messing with python3-{pip,venv}. I'll reintroduce it now, so I can end the work day with a working docker image

So even if I can see your argument that in Docker we want /usr/local as venv and therefore must avoid conflict with /usr – that now necessitates doing your python3 -m pip trick in in core as well.

On top of that: in ocrd/core, we don't even manage venvs – everything is native/system-wide. So at least here we do need python3-pip.

Why does the docker build try pip3 install --upgrade pip setuptools outside of a virtual environment?
And why did we switch from pip to pip3 again?

I am afraid both goes in the wrong direction. We should stick to using Python only in virtual environments, and then we can always use pip.

I will investigate it further tomorrow, but no more hotfixes today :)

Why does the docker build try pip3 install --upgrade pip setuptools outside of a virtual environment?

Like I said: in ocrd/core, we have no venv, only a system-wide installation. (Which is arguably better than the pseudo-venv in ocrd_all, but there we also need sub-venvs, so...)

And why did we switch from pip to pip3 again?

Because that's what python3-pip delivers. pip is not available (unless someone installs Python 2 or sets up their local venv).

I will investigate it further tomorrow, but no more hotfixes today :)

No need to: the only failure now comes from core-cuda, which we already knew would fail, because we (intentionally) did not update its base image to Ubuntu 20, so OpenCV does not build anymore. – Like I said, I am still investigating whether we can actually move towards cuda-11 libcudnn8.

that's what python3-pip delivers. pip is not available

I just tried it in the Docker container, and pip is available:

root@a3351d49b876:/# ls -l /usr/bin/pip*
-rwxr-xr-x. 1 root root 365 Feb 28 10:41 /usr/bin/pip
-rwxr-xr-x. 1 root root 367 Feb 28 10:41 /usr/bin/pip3

I just tried it in the Docker container, and pip is available:

In which container?

I tried ocrd/core and its base container (that one after installing python3-pip).

I tried ocrd/core and its base container (that one after installing python3-pip).

Still don't know an which state of the Dockerfile. This is becoming tedious. See original bug if you want to help.

pip3 was needed for Ubuntu 18.04 when it was used without a virtual environment because its python3-pip did not install /usr/bin/pip. The reason is simple: old Linux versions reserved pip for Python 2. The docker build failed because it was based on an NVIDIA container which was based on Ubuntu 18.04. cd /usr/bin && sudo ln -s pip3 pip would have fixed it, too.

Ubuntu 20.04 and other current Linux distributions no longer provide Python 2. Its python3-pip installs /usr/bin/pip.

So with current supported software or when using virtual environments (my preferred way) pip3 is not needed.