sub-venv logic ineffective when main venv was already active about ocrd_all

[stweil]

Option 2 is the right one. See example here.

[stweil]

This does not happen when using virtualenv proper to create the sub-venv – which makes me wonder why we moved back from python3-virtualenv to python3-venv in the first place.

The answer is here: https://packaging.python.org/guides/installing-using-pip-and-virtual-environments/.

[bertsky]

Thanks @stweil. I'll use the deactivate approach then.

[stweil]

But under this circumstance, creating sub-venvs does not work as expected: python -m venv DIR does not create new pip / pip3 entry points then, which causes subsequent pip calls to use the main venv again.

I tried to reproduce this issue on Ubuntu, but everything works for me as expected. How can I reproduce the problem?

My test sequence was this:

python3 -m venv venv
source venv/bin/activate
python3 -m venv venv/local
source venv/local/bin/activate
pip install wheel

[bertsky]

I tried to reproduce this issue on Ubuntu, but everything works for me as expected. How can I reproduce the problem?

My test sequence was this:

python3 -m venv venv
source venv/bin/activate
python3 -m venv venv/local
source venv/local/bin/activate
pip install wheel

Damn. Cannot reproduce myself anymore 😦

[stweil]

So can we close this issue?

[bertsky]

Yes, let's close!