IDE configuration for xarray development

[benbovy]

I'm curious of which IDE / config do use xarray devs/contributors.

I'm currently using Pyright (in Emacs 27 / Emacs-lsp on MacOS 11.2) and it is painfully slow, especially when larger files like xarray/core/dataset.py are open (in other words: all the time).

For instance, analysing xarray/core/dataset.py using Pyright's command line takes ~ 3 s and gives 25 errors (9 s / 51 errors when activating "useLibraryCodeForTypes").

If my understanding is correct, it shouldn't take that long when working on the files (pyright only analyses deltas in watch mode?), but still, as I'm typing Emacs gets stuck for looong seconds analyzing all open files, it's very laggy.

The number of reported errors is also annoying, it makes my IDE code checker useless.

I'm wondering if that's because my IDE environment is not properly configured. I've tried other languages servers like pyls or mspyls but things were even worse.

Anyone experiencing the same issues? Or does everyone use VSCode (which I guess yields better experience out of the box, e.g., with Pylance)?

[andersy005]

Anyone experiencing the same issues? Or does everyone use VSCode (which I guess yields better experience out of the box, e.g., with Pylance)?

I use vscode with Pylance language server, and my experience has been great so far...

[max-sixty]

Same! Which also uses pyright.

[benbovy]

I'll give a try with VSCode / Pylance (using the same pyright config parameters) to see how it compares (reported errors and performance).

[shoyer]

I also have a good (or at least OK) experience with VS code.

[max-sixty]

@benbovy that does not sound fun, let's try and figure it out. If it exists for you it probably exists for others too.

Could you show the errors you get?

FYI the only slowness I get is auto-formatting the huge test files like test_dataset.py. I'm not sure if that's their length or that the class is a single parent AST node — from before the pytest days. We could think about breaking those files up a bit.

[benbovy]

Could you show the errors you get?

Checking dataset.py and dataarray.py, a good part of the errors actually make sense (introduced by the changes in #5102), even though checking with mypy (pre-commit/CI) is passing. I'll need to fix these.

For the rest, I'll probably need to investigate more what causes so much slow down in my config. That's not easy to figure out, though. It gets worse when I have more files opened, and it depends on which files are open.

[dcherian]

Greetings emacser! I just started using natively compiled emacs along with doom and it's great. the native-comp branch was just merged to master, so it should be stable. Just have to spend ≈30 minutes compiling it and all the doom packages.

[benbovy]

Salutations emacser! I'm using emacs-doom too but I've been waiting before trying the natively-comp branch, looks like it's time now! I'm curious to see if it will solve the performance issue that I encounter, though. I was rather thinking of something I have not properly configured or a bottleneck on the pyright side. I know that pylance is built on top of pyright, but I'm not sure what features it brings (optimizations, type stubs?). Unfortunately we just can't use it with emacs-lsp.

[keewis]

Since you had pinged me in #9570: I'm using standard emacs (gtk), installed through my OS's package manager.

I don't use any language server whatsoever; I had tried that one or two years ago and found it taking up way too many resources to be useful (that was with pyls, and my tests just now show that the jedi-language-server might work but is also kinda slow). Of course, this also means that I'm not using any autocompletion, either, and I'm running linters and formatters through pre-commit.

So all in all a pretty basic setup, although I do use magit and forge to have a nicer interface for git.