Path Error when using shell #51
Comments
|
@furkanusta thanks for the report! I believe I #53 fixes this, let me know if latest master doesn't work for you. |
flying-foozy
added a commit
to flying-foozy/virtualenvwrapper.el
that referenced
this issue
Nov 13, 2019
…tion If a virtualenv is normally activated, environment variable VIRTUAL_ENV does not end with "/", and its value is equal to sys.prefix in the python process. On the other hand, virtualenvwrapper.el before this commit makes VIRTUAL_ENV end with "/". Therefore, its value is different from sys.prefix in the python process spawned from Emacs. VIRTUAL_ENV ending with "/" might cause issues. For example, Jedi https://github.com/davidhalter/jedi stops working, in such case. Jedi creates PIPE-ed child process at each completion requests or so, and keeps them opened, if VIRTUAL_ENV is not equal to sys.prefix in child process. Finally, it stops working soon, because of EMFILE ("Too many open files"). Though child process management of Jedi may have to be more efficient, virtualenvwrapper.el also have to make VIRTUAL_ENV not end with "/", IMHO, because normal virtualenv activation does so, and the format of environment variable is a kind of API for inter process co-operation. According to commit f7c97e2 ("ensure venv-location has slash on end") for issue porterjamesj#51, there are some code paths, which expect venv-current-dir to end with "/". Therefore, this commit eliminates tail "/" of venv-current-dir at each assigning non-nil value to VIRTUAL_ENV, instead of making venv-current-dir not end with "/".
flying-foozy
added a commit
to flying-foozy/virtualenvwrapper.el
that referenced
this issue
Dec 16, 2019
…tion If a virtualenv is normally activated, environment variable VIRTUAL_ENV does not end with "/", and its value is equal to sys.prefix in the python process. On the other hand, virtualenvwrapper.el before this commit makes VIRTUAL_ENV end with "/". Therefore, its value is different from sys.prefix in the python process spawned from Emacs. VIRTUAL_ENV ending with "/" might cause issues. For example, Jedi https://github.com/davidhalter/jedi stops working, in such case. Jedi creates PIPE-ed child process at each completion requests or so, and keeps them opened, if VIRTUAL_ENV is not equal to sys.prefix in child process. Finally, it stops working soon, because of EMFILE ("Too many open files"). Though child process management of Jedi may have to be more efficient, virtualenvwrapper.el also have to make VIRTUAL_ENV not end with "/", IMHO, because normal virtualenv activation does so, and the format of environment variable is a kind of API for inter process co-operation. According to commit f7c97e2 ("ensure venv-location has slash on end") for issue porterjamesj#51, there are some code paths, which expect venv-current-dir to end with "/". Therefore, this commit eliminates tail "/" of venv-current-dir at each assigning non-nil value to VIRTUAL_ENV, instead of making venv-current-dir not end with "/".
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Hi, When I use venv-projectile-workon and then open up shell, it says
...venvbin/activate: No such file or directory
I've fixed this issue by wrapping venv-current-dir with (file-name-as-directory ) at lines 220, 481 and 499
I'd like to send a pull-request but I don't know much elisp and, thus, I am not sure whether it is a correct fix also I am not sure whether all three of them are necessary.
The text was updated successfully, but these errors were encountered: