Open solovyevn opened 8 years ago
The reason is that sys.path
is saved prior to modification, and restored after deactivation. If another plugin or script uses the same strategy or modifies it, those changes would get lost. I'm open to suggestions on how this can be handled better.
What about this. The plugin can save the site-packages path that gets added during activation. On deactivation, remove the matching path from sys.path
with something like remove(index(sys_path, site_pkg))
I'm sorry, I didn't have time to look through the code, so I just posted it as an issue I came across, and not the pull request.
Your proposed solution looks like a good idea, it will work for any posistion in the sys.path
and doesn't affect any other plugins. Guess it can be simplified to sys.path.remove(site_pkg)
.
Nice one. Thanks!
No problem! )
Note: I use pyvenv for virtual environments, I don't know if the same problem occurs for virtualenv users.
The issues is probably related to how the sys.path is handled for activation and deactivation of virtual environment. The vim-virtualenv plugin is not always run/initialized first relative to other plugins (that may also modify sys.path), but it looks like :VirtualEnvDeactivate command's code assumes, that the venv's site-packages entry is the first in sys.path. This leads to some entries being erased from the path, when the command is run. See example and actions to repeat the issue below.
Scenario 1 (starting vim when venv is already active, the path gets erased):
vim somefile.py
;:python import sys; print(sys.path)
;:VirtualEnvDeactivate
;:python import sys; print(sys.path)
;:VirtualEnvActivate venv_name
, and check sys.path again there're no directories for YouCompleteMe, and the directory for venv's site-packages is the first in the list.Scenario 2 (manual virtual environment activation in vim, works as expected):
vim somefile.py
;:python import sys; print(sys.path)
;:VirtualEnvActivate venv_name
, and check sys.path again;:VirtualEnvDeactivate
, and check sys.path again;