`jedi:server-pool--start` ought to consider `VIRTUAL_ENV` variable as part of its hash key

[glyph]

I have been wondering why emacs-jedi would sometimes find stuff in the wrong directory for quite some time now, and I just realized that it's because although it would honor a correctly-set VIRTUAL_ENV variable when starting the server, it would not consider that part of the hash key. Therefore, since I have a different VIRTUAL_ENV automatically computed for every project directory, if I have two projects open at once in Emacs, whichever one opened first control's jedi's view of sys.path.

I worked around this by adding (set (make-local-variable 'jedi:server-args) (list "--virtual-env" env-to-use)) into my python mode hook, which appropriately mangles the hash key, but this should really be automatic.

[glyph]

@immerrr FWIW the fact that things broke actually forced me to root-cause this problem, and thus start having a much better time with emacs-jedi, as it has stopped being weirdly unreliable when switching projects without rebooting Emacs ;)

[immerrr]

Yeah, i think the original idea was to use the VIRTUAL_ENV environment variable transparently, but I can see how that can be a problem w.r.t. the server pool. I may have even tripped on the same problem myself, before moving to lsp stuff that is.

[glyph]

Yeah, i think the original idea was to use the VIRTUAL_ENV environment variable transparently, but I can see how that can be a problem w.r.t. the server pool.

Yeah, the transparent handling is great! I just think it needs to take it into account the venv regardless of whether it's specified by argv or by env.