If added, this makes the virtualenv read the main site-package from brewed Python,
and especially makes it read our sitecustomize.py file, which will
modify the sys.executable path.
See the full discussion at:
https://github.com/Homebrew/brew/pull/8873
I also took the opportunity to not include test deps, as these will
be not be installed, so the .pth file should not contains references
to site-packages from test deps.
Previous packages on Linux did already contain the wrong lines in the pth file,
for example:
cat /home/linuxbrew/.linuxbrew/Cellar/aws-google-auth/0.0.36_1/libexec/lib/python3.8/site-packages/homebrew_deps.pth
import site; site.addsitedir('/home/linuxbrew/.linuxbrew/opt/python@3.8/lib/python3.8/site-packages')
import site; site.addsitedir('/home/linuxbrew/.linuxbrew/opt/libxml2/lib/python3.8/site-packages')
This might have caused subtle bugs for some packages but not for others.
From PEP 394
https://www.python.org/dev/peps/pep-0394/#for-python-script-publishers
In cases where the script is expected to be executed outside virtual environments,
developers will need to be aware of the following discrepancies across platforms and installation methods:
Older Linux distributions will provide a python command that refers to Python 2, and will likely not provide a python2 command.
Some newer Linux distributions will provide a python command that refers to Python 3.
Some Linux distributions will not provide a python command at all by default, but will provide a python3 command by default.
When potentially targeting these environments, developers may either use a Python package installation tool that rewrites shebang lines
for the installed environment, provide instructions on updating shebang lines interactively,
or else use more specific shebang lines that are tailored to the target environment.
On High Sierra and Mojave, virtualenv 16.x does not build when used with
system Python
Fall back to an older virtualenv version, which is known to work.
