...
This behavior could arise for any number of reasons. The most common reason that RC sees is that you've forgotten to load the correct python module prior to activating your virtual environment. Because virtual environments (as configured on O2) are necessarily dependent on their source installations, it is required to load the python module from which you created that virtual environment before activating it, every time you use it. If you have made sure you have already done so, and in the correct order (load module THEN activate virtual environment), then please submit a ticket with as many details as possible (including terminal output and command history such that we know where your environment lives and how to replicate your issue) to rchelp@hms.harvard.edu.
| Note |
|---|
Package mismatch errors with environments that use python/3.7.4You may run into a problem where your environment detects a version of a package that lives in /n/app/python/3.7.4-ext and is unable to access/uninstall/upgrade/downgrade to a version that you desire. The quickest way to address this is to execute unset PYTHONPATH after loading the python/3.7.4 module but before activating your virtual environment. If you have personally modified the $PYTHONPATH variable for other purposes, you may need to re-populate it after removing the module package path from the variable (you can check if/how it is populated prior to executing unset by running echo $PYTHONPATH). If /n/app/python/3.7.4-ext/lib/site-packages is not the only path on $PYTHONPATH and unset-ing it is not worthwhile, you may choose to manually excise the path from the variable using whatever methods you find appropriate, though this is far less trivial than simply unset-ing it and repopulating it afterward, and we are unable to provide any general guidance to do so. If you require assistance with this sort of surgical modification of $PYTHONPATH, please contact us at rchelp@hms.harvard.edu and we can assist you with the process. |