Avoid conflicts with OS python packages by using Python venv in /opt/rucio

[bziemons]

Closes: #458

[bziemons]

Please mind this needs manual testing. I might have missed something

[rcarpa]

I like, a lot, the idea of having a venv for rucio rather than using the global python libraries, but I wonder if mixing rucio binaries and the venv ones is a good idea. I would personally put the venv in a different location

[Geogouz]

Right now, the baked venv at /opt/rucio is basically hidden by the bind mounts we use in the docker-compose. So we should adjust this on rucio/rucio side too. But we could maybe also use a venv like /opt/rucio-venv, set the PATH to that venv and PYTHONPATH=/opt/rucio/lib for the module resolution.

Also, another idea might be to break this into separate PR per container. It feels like reviewing all of them at once, comes with the disadvantage of having a huge scope. Which means that this will take quite a long time to be merged. I think we should at least start with the dev container and see how this goes. That one is not very dangerous to merge and play with. Dunno.

[rcarpa]

I like the idea of trying it on the dev container first. Then do the others.

[Geogouz]

@bziemons Should I make an issue only for the dev image, and then have a PR that introduces the venv there in order to test it separately? And then once we decide on the approach and merge it, we can reflect the changes there also to the rest of the containers here.

[Geogouz]

@bziemons Should I make an issue only for the dev image, and then have a PR that introduces the venv there in order to test it separately? And then once we decide on the approach and merge it, we can reflect the changes there also to the rest of the containers here.

Or all at once?

[bziemons]

@bziemons Should I make an issue only for the dev image, and then have a PR that introduces the venv there in order to test it separately? And then once we decide on the approach and merge it, we can reflect the changes there also to the rest of the containers here.

I think that's a good idea. I agree that it is beneficial to do the dev image first. I won't have time to work on an update for this for a couple of days.

[bziemons]

I took another look at this and the only issue when having the Rucio venv in /opt/rucio/ is the rucio-dev image, which then is used to bind-mount /opt/rucio/bin and /opt/rucio/lib (clashing with the venv). In my opinion I would rather move the dev environment closer to production, mount the source directory at /opt/rucio/src and utilise pip install --editable. I have done this locally in a quick proof of concept and it does run fine, solving several of our issues. To discuss this, I will probably sum up all changes I made and I guess we'll discuss them in a developer meeting.