python-language-server icon indicating copy to clipboard operation
python-language-server copied to clipboard

Publish an official extension for vscode

Open ghisvail opened this issue 8 years ago • 12 comments
trafficstars

Are there any plans to make the vscode-client available as an official extension, or is it designed for internal use only?

It could join the family of existing language server plugins like Java, Scala or Rust. There is already a Python plugin officially sponsored by Microsoft but it is significantly heavier in comparison.

Thoughts?

ghisvail avatar Nov 23 '17 17:11 ghisvail

What is meant by “heavier” and which is heavier, pyls or the MS extension?

gvanrossum avatar Jul 04 '18 20:07 gvanrossum

The MS extension could be considered a fat client. There’s a fair bit of typescript code that calls into Python where necessary.

Pyls tried to keep all logic in the server. The src/extension.ts file has all the client logic we need.

I’m not sure if @ghisvail is referring to performance? I’ve not compared the two.

In terms of features, I’d say currently the MS extension is more complete. Although goes without saying, any work done to further Pyls will benefit all language server clients.

gatesn avatar Jul 04 '18 22:07 gatesn

Got it. I also noticed what I'd call buggy behavior when using pyls. E.g. when there's a class C, typing x = C() is quite insistent in suggesting chr instead and hitting Enter leaves the line looking x = chr with the cursor at the end of the line. I personally find it quite bad if just typing correct code results in something other than what I literally typed. (Then again MS software has been auto-correcting straight quotes into "smart" ones for decades, so I realize I'm at the losing end of this debate.) Quite likely I should report this somewhere else though (perhaps it's due to Jedi?)

gvanrossum avatar Jul 04 '18 22:07 gvanrossum

Our completion wrapper is indeed a very thin layer over Jedi: https://github.com/palantir/python-language-server/blob/develop/pyls/plugins/jedi_completion.py

I would be willing to consider alternatives, or even build one if it makes sense, but Jedi seems like the standard tool even now.

I’d be interested to know if you are aware of any other solutions? Currently we need Pyls to support Python 2, although I’m hoping we can remove that requirement by end-of-year and include some of the vast capabilities of tools like Mypy as standard.

gatesn avatar Jul 05 '18 22:07 gatesn

I don't know much about how Jedi works -- IIRC I tried it a few years ago and found it rather primitive. If the behavior I saw yesterday is due to Jedi I don't think it's mature enough.

At Dropbox we're going to work on deeper integrating of mypy with various editors, and LSP is one of our targets. (I came across pyls doing some research for this project.) The main reason why we think that mypy will be more effective than Jedi is that we now have a mypy daemon which keeps all inferred type information in memory. It can also quickly update this information whenever a file is changed. It's too soon to say how successful we'll be, but it's quite possible that eventually mypy will be able to replace Jedi for most or all of its functionality. (Note that mypy supports Python 2 too.)

gvanrossum avatar Jul 06 '18 00:07 gvanrossum

when there's a class C, typing x = C() is quite insistent in suggesting chr instead and hitting Enter leaves the line looking x = chr with the cursor at the end of the line.

I don't think this is an issue with Jedi. If completion is requested after x =, Jedi returns the class C and chr among other candidates. It's then up to the client to avoid displaying and selecting chr after typing C(. So I would say it's a bug with the client or VS Code itself (unless I didn't understand the issue).

micbou avatar Jul 06 '18 01:07 micbou

@gvanrossum, is there any news regarding integration of mypy with various editors? I could not find any information. I am interested on working on a mypy-based language server -- I've made a proof of concept with dmypy providing hover/go-to-definition functionality within VS Code. (It has helped that Python 3.8 added end_line and end_col_offset to the AST.)

matangover avatar Apr 17 '19 06:04 matangover

@matangover Sorry, there's no progress. We may start working on this over the summer, but no promises.

gvanrossum avatar Apr 17 '19 15:04 gvanrossum

It's a year later. Is the idea abandoned?

adamal avatar Jun 12 '20 16:06 adamal

Unfortunately, we don't have plans to create a VSCode extension for this server because most contributors use it for other editors and IDEs.

ccordoba12 avatar Jun 18 '20 21:06 ccordoba12

Can we add some documentation on enabling it for some IDEs? I assumed that installing the pip package would somehow register it for vscode to catch, but that doesn't seem to be the case.

munael avatar Jul 21 '20 06:07 munael

@ccordoba12 What about the developers who want to simply use the extension (without developing it)? I mean, it strikes me from the ReadMe and integration-related questions/issues that there's so little support on actually using it. Or maybe I just had overly optimistic expectations regarding "readiness for use"... The description sounds like the perfect extension, and given that it reuses existing components, it sounds even within reach. But without an actual integration, it stays just a dream (for hobbyist coders like me).

Stercator avatar Jan 08 '22 11:01 Stercator