So as I understand it, the packages outside the virtualenv cannot access or use the packages within it for its dependences
It definitely can, if you activated the virtualenv or if you you have the virtualenv in your PYTHONPATH. Note that this situation is mostly a source of error. For example, you have a system package depending on numpy, and you have a newer version of numpy in your virtualenv, that one might be picked.
packages within the virtualenv firstly triy to use packages within it for its dependencies and when it has access to the system, uses system packages when it cannot fulfill its dependencies from venv internal packages. Is that right?
The order of processing of the python import is really important. It's quite clear that the path in your PYTHONPATH are ordered, but what about activated virtualenv?
Well this is the weird thing: when you activate a VIRTUALENV, it does not add itself to your PYTHONPATH. Instead, it changes the path of your python executable to the virtualenv. The virtualenv's libraries are alongside this executable, so magically resolved. Testing on my laptop, it seems that these packages are resolved before the PYTHONPATH is checked for these dependencies.
Do you think your scripts would help? I should probably install virtualenvwrapper with apt-get instead of pip right?
Okay I'll write a blog post soon then.