The CircleCI documentation mentions that Python environments automatically set up a virtualenv:
When Circle detects Python, we automatically use virtualenv to create an isolated Python environment.
I would highly prefer that it did not attempt to do any management of the virtual environment. One reason why is that users do not run shells inside a virtualenv locally, so our test setup scripts need to create an environment. It would be good to keep this behavior consistent between our CircleCI runner and our local environment.
Another reason why I don’t want this behavior is because the virtualenv version is 1.10; the latest virtualenv version is 15.1, and contains numerous stability and security fixes.
Furthermore it appears to complicate getting things working; for example when I try to run the following in dependencies/override:
pip install --upgrade pip virtualenv
fails with the following baffling error:
virtualenv venv Please use the *system* python to run this script Traceback (most recent call last): File "/home/ubuntu/webhooks/venv/bin/virtualenv", line 9, in <module> load_entry_point('virtualenv==15.0.1', 'console_scripts', 'virtualenv')() File "/home/ubuntu/webhooks/venv/lib/python2.7/site-packages/virtualenv.py", line 708, in main symlink=options.symlink) File "/home/ubuntu/webhooks/venv/lib/python2.7/site-packages/virtualenv.py", line 921, in create_environment site_packages=site_packages, clear=clear, symlink=symlink)) File "/home/ubuntu/webhooks/venv/lib/python2.7/posixpath.py", line 360, in abspath if not isabs(path): File "/home/ubuntu/webhooks/venv/lib/python2.7/posixpath.py", line 54, in isabs return s.startswith('/') AttributeError: 'NoneType' object has no attribute 'startswith' make: *** [venv] Error 1
I’m not sure how to work around this; I guess I could call
deactivate before literally every command I run ?
It would be nice if there was an option to opt out of this.