Jedi creating too many processes when VIRTUAL_ENV not set?

[dsedivec]

It seems like there have been a few reports of "too many open files" since recent commit 862f611, most of which are in other projects I think. Examples:

• completion do not work with pwntools #1229
• 'Too many open files' error coming from the server palantir/python-language-server#431
• IOError(24, 'Too many open files') while editing python2 on windows 10 syl20bnr/spacemacs#11399

On my macOS system, using anaconda-mode from Emacs, I think there may be a problem when the VIRTUAL_ENV environment variable is not set. I think Environment.path gets set from sys.prefix? In the case where VIRTUAL_ENV is not set, environment.path != os.environ.get('VIRTUAL_ENV') in get_cached_default_environment will always be false I think, which seems like it will clear the cached environment and start a new environment over and over?

Should the new check added in 862f611 avoid calling clear_cache if VIRUTAL_ENV is None?

(Of course, that doesn't help if someone changes it from an actual virtualenv path to None. Maybe an environment's VIRTUAL_ENV environment variable at creation time should be stashed away somewhere, and you just check that directly?)

On my system I think I have seen this manifested by having ~76 instances of the following subprocesses under the top-level Jedi process started by anaconda-mode:

/usr/local/bin/python /Users/dale/.emacs.d/anaconda-mode/0.1.13/jedi-0.13.1-py2.7.egg/jedi/evaluate/compiled/subprocess/__main__.py

anaconda-mode does happen to be starting a Python interpreter inside a virtual environment by virtue of my PATH, but based on my analysis above, I don't think that's relevant.

Sorry if this is not a bug, or just an artifact of other projects misusing Jedi. I'm afraid I only use Jedi indirectly from things like anaconda-mode or python-language-server so this is a hasty and probably incomplete diagnosis. I wanted to open an issue to get an expert opinion.

Indirectly or not, though, I've used Jedi for years and it's been a godsend! Thanks for your work!

[bet4it]

I'm trying to solve it in #1238.

[jschwinger233]

got the same issue after appending - bash --no-rehash to eval "$(pyenv init)" at ~/.bashrc

[davidhalter]

I feel like this is fixed on master now, since @bet4it contributed a fix in #1238 (which was just merged).

Please let me know if there are still issues with this.

Sorry for taking so long to fix it.

[davidhalter]

I only just realized how bad this issue was. Big sorry for that. I therefore did a release immediately.