Why does it install `pip` into the generated virtualenv?

[dimaqq]

The issue that I'm having is that building a component that uses catkin-virtualenv twice with some Python dependencies getting changed dies with this error:

  File "/usr/lib/python3/dist-packages/OpenSSL/crypto.py", line 1573, in X509StoreFlags
    CB_ISSUER_CHECK = _lib.X509_V_FLAG_CB_ISSUER_CHECK
AttributeError: module 'lib' has no attribute 'X509_V_FLAG_CB_ISSUER_CHECK'

I've traced it down to catkin-virtualenv installing pip into the venv that it creates.

However, the version of that pip is different from the system pip.

Which means that when I try to build again, and catkin tried to install the deps into the virtual environment, it calls pip which is a hybrid of two pip versions, and they don't agree on pyopenssl (I think), leading to this traceback from crypto.

This begs the question though...

Why install pip into the generated venv?

What is the rationale for that?

[BoyanH]

This is the default functionality of Python's venv module, as described in the docs. I believe the main reason for this is to further decouple the virtual environment from the rest of your system. There might be other technical reasons which I yet don't understand, such as it perhaps being difficult to enforce pip to work on the active venv in a platform-agnostic way. I was also curious about this, so I posted Why is pip installed in virtual environments by default? on Stackoverflow.

[dimaqq]

Looks like the consensus on stackoverflow is that having pip installed into the virtualenv by default is kinda standard.

This lease two possibilities:

1. either use the special flag to no install pip into venv, or
2. let pip get installed, but also install openssl/crypto/etc so that pip actually works