[WIP] Jedi project sys.path manipulation

[theangryangel]

At work I use an upstream project which is structured in a way where to get Jedi to autocomplete, etc. we need to modify the sys.path (I can explain more if required, but think a root project, with a vendors directory, almost). Under coc-python I use the python.autocomplete.extraPaths feature to get autocomplete, etc. working.

This is an extremely early implementation (no tests, total hack) to find out if you're happy with the concept of adding something like this to jedi-language-server. If yes I'll find a way to tidy it up, get some tests in, etc.

From a coc-jedi perspective adding jedi.extraPaths: ['path1/', 'path2/'] to the project's coc-settings.json with this PR gets me working.

[pappasam]

@theangryangel I completely support this feature! And don't worry too much about this being "tested", this application's testing standards have been... regrettable so far. Honestly, I'm holding out for an LSP testing framework; until then, I just test manually with coc.nvim / rely on linting / static type checking. I (admittedly lazily) don't want to write bespoke unit tests that become a burden to maintain as the LSP itself evolves.

Regarding implementation, I agree with extraPaths argument. We'll pass that into initializationOptions: https://github.com/pappasam/jedi-language-server#configuration . You should add a cached_property called initializationOptions_extraPaths to jedi_language_server.initialize_params_parser.InitializeParamsParser that returns a list of extra paths (defaulting to empty list). When this is implemented, I'll add a jedi.extraPaths configuration option to coc-jedi and the cycle will be complete!

Since testing is minimal outside of static type checking / linting at this time, we should rely on statically-defined types as much as possible. Because of that, we should avoid mutating workspace and adding attributes.

We should avoid overriding sys_path for jedi projects; I think a lot of magic happens here and we don't want to simply override with the sys.path from jedi-language-server. We should instead rely on the added_sys_path argument; just pass a list of strings here. Based on my reading of _get_sys_path, duplicates are removed at the end.

Finally, we can consider creating only 1 Jedi project on the __init__ method of JediLanguageServer. If we define it here, it'll be statically inferred AND only called once (which might give us some nifty performance improvements). You'll need to pass this project as a new argument to `jedi_language_server.jedi_utils.script), but I think it might be worth it.

Thanks for opening this PR and please let me know if you have any clarifying questions for me about the above!

[pappasam]

@theangryangel do you have time to work on this soon? If yes, I'll wait for you to respond to the above before implementing anything myself.

[theangryangel]

Probably one evening this week, family permitting :) I realise it’s not a huge amount of work but I’m struggling to fit it in during work hours this week - thought it was going to be quiet but no such luck 😅

[pappasam]

@theangryangel are you still working on this? I don't want to implement something if you're actively working on it, but I'm also happy to take it from here if your time is being occupied by other priorities

[theangryangel]

Honestly just haven’t gotten around to it yet, if you wanna deal with the issue that’s not a problem 👍

[pappasam]

@theangryangel I've added this feature. See: https://github.com/pappasam/coc-jedi#jediworkspaceextrapaths, or https://github.com/pappasam/jedi-language-server#configuration if you're not using coc-jedi. Thanks for this PR!

[pappasam]

Also, please let me know if you discover any bugs / inconsistencies with the documentation.