Remove --user from pip install in postCreate.sh

[Jongmassey]

venv is activated prior to this script execution following this change to the dockerilfe so --user installation no longer allowed and errors reported by @lucyb and replicated by @Jongmassey .

Rather than remove --user and install opensafely into the virtualenv, use a direct path to the system pip3 and thus decouple it from the virtualenv entirely.

[iaindillingham]

Could you describe the problem more clearly in both the commit message and the PR description? I followed the link to opensafely-core/research-template-docker#26, but there's no description of that problem, either.

This is a good example of an issue where the solution is small relative to the description of the problem. However, the description of the problem will be invaluable to our future selves. I can imagine future me running git blame on .devcontainer/postCreate.sh, finding the commit message, finding the PR description, and thinking "Why on earth did Jon do that?"

From my perspective, I think the problem is that a venv is automatically activated in each shell in a dev container.¹ When pip install --user ... is executed within a venv, it fails:

ERROR: Can not perform a '--user' install. User site-packages are not visible in this virtualenv.

So, the problem is that .devcontainer/postCreate.sh is executed in a shell in a dev container with an active venv. It fails at the call to pip install.... The solution is to modify the call to pip install..., changing a --user install to a local install.

Describing the problem more clearly highlights the tight coupling between research-template and research-template-docker. Is there any way we could avoid assuming that a venv is activated? Could we use the absolute path to pip?

Footnotes

1. This is because source /opt/venv/bin/activate appears in /home/rstudio/.bashrc. It's important to realise that rstudio is the user account on the dev container; it's the user account that runs RStudio, but also the user account that runs VS Code. ↩

[Jongmassey]

clearly highlights the tight coupling between research-template and research-template-docker

This is something we've discussed when deciding to put the latter in its own repo. In our current state with no tests that test across both it's very easy to make breaking changes.

Is there any way we could avoid assuming that a venv is activated?

I think this is a reasonable assumption given the entry in .bashrc. IIRC you raised an issue that the venv activation wasn't very robust prior to this change - is there a method of activation you'd prefer? (bearing in mind we need to account for both the CLI and the MS Python extension)

Could we use the absolute path to pip?

/usr/local/bin/pip3 install opensafely --user works

I've got no preference as to installing in the venv vs user-installing. If there's a good reason for one of the other please say and I'll do it the way you want. That or just push a suitable commit to this PR (or a new one).

[iaindillingham]

We should use the absolute path to pip, as this weakens the coupling. Assuming that the venv exists and is activated is two links in the coupling; assuming that the venv exists is one link in the coupling.

Please, though, describe the problem more clearly in both the commit message and the PR description. Doing so will be invaluable to our future selves.