This fixes two issues with the caching on Windows / APPDATA

[mmaeusezahl]

The problem is that Jedi starts to fill the organizational storage space in %APPDATA% on Windows. In my case (with just minimal use) I have a 400MB Jedi folder that gets synced across our organizational network each time I log in (I am using Visual Studio Code which in turn uses Jedi).

Fixes

• The cache directory should really be %LOCALAPPDATA%
• ~ is not a meaningful directory on Windows. It should really be
  os.path.expanduser('~'). To be honest it is probably always safe to
  assume that os.getenv('LOCALAPPDATA') executes to something sensible
  on any Windows system that hasn't been tampered with.

Reasoning and a historical side note:

This issue was already reported once here: #926

It got then partially fixed, but only for parso in a different place (thinking of which, the second issure should probably also get ported there as well): davidhalter/parso#1

Someone also temporarily fixed it in pythonVSCode (now maintained as microsoft/vscode-python): DonJayamanne/pythonVSCode#1035

But it got lost in microsoft/vscode-python@20a7bd5 when Jedi was introduced as an external dependency much rather than pulling it in as external code.

[davidhalter]

Good points. That was really my fault. I simply forgot that Jedi has also a separate path (it's debatable if that makes sense).

Thanks for the research and this fix!

I'm merging, because I believe that everybody forgot about this. It would still be nice if @micbou could verify that this is correct.

[davidhalter]

I also patched it in parso: 15403fd998c2e60f9f9dc7def819dfc0ff0926f8. I don't think it matters much since as you say os.getenv('LOCALAPPDATA') should always be something meaningful. However now they should both be very similar.

[mmaeusezahl]

Maybe it would be sensible to use the appdirs package in the first place instead of having roughly the same (error prone to future Windows cache locations) code in two code-bases?

Thanks for the quick merge!

[davidhalter]

That's not really an option, because I don't want dependencies for something as small as that.

[mmaeusezahl]

Alright I try to keep it that way too (usually) 👍

Looking at the code of appdirs, the main difference seems to be that it tries to call a low-level Windows function instead of os.getenv. I can't really tell when this would be necessary -- it's a thing that Python would hardly support anyway.