Ability to control dependencies

[DonJayamanne]

My plan is to utilize this language server in my Python extension for VS Code.

However, there are a few gaps (obviously) in your implementation and my extension. For instance a combination of multiple linters, and also provide the ability for users to customize each linter with command line args (configurable via the settings.json or via linter specific config files - this isn't an issue).

Similarly I support two formatters in my extenion.

So, the question comes down to what's the best way forward for me, in utilizing this language server.

[gatesn]

So currently the linters/formatters and any other providers are declared at the top of the PythonLanguageServer class.

The idea behind this (although not implemented at the moment) is that the initializationOptions can be used to choose between different providers. Notice we already use multiple linters at the same time and could easily configure different formatters on initialisation.

In terms of linter / formatter config, again some of this could be passed in the initializationOptions but we already support reading config from setup.cfg, tox.ini files etc. that are available in the workspace. Unfortunately this is currently done manually instead of relying on the tools' built-in config parsing meaning results may vary. An improvement here might be to shell out to pycodestyle / pyflakes / any other linter setting the working directory to the workspace root and then parsing stdout.

[DonJayamanne]

It seems the linters, intellisense providers, etc all run in a synchronous and single threaded manner. I feel that this could prove to be quite slow with larger code bases (with linters, code definition, hover, etc all happening in very quick succession). Wouldn't it be better to run the linters in a separate thread or process, with callbacks?

[gatesn]

I agree multi-threaded would be preferable, happy to look at PRs! Right now almost all the providers act only on a single file so performance issues from large repos tend to be limited to only a few cases (where jedi looks at the entire python path for symbols e.g. code completion / go to definition etc).

We can open an issue for multi-threading but until it's clear performance is an issue I likely won't have time to make the change.

[gatesn]

I'm going to close out this issue since its a bit generic and vague. I think there are a couple of issues up for configuration of providers and for performance. Feel free to open any other issues separately if not covered by those two. Thanks!