Adds experimental Go spec

[joelschutz]

References

• Adding Go Spec #905

Code changes

• A simple initial spec for gopls

User-facing changes

• Adds minimal support for Go

Backwards-incompatible changes

• Nothing yet

Chores

• linted
• tested
• documented
• changelog entry

[github-actions]

👈 Launch a binder notebook on branch joelschutz/jupyterlab-lsp/goplsImplementation

[bollwyvl]

This is... fine. But adding new heavyweight languages is... heavy, even if we can get them form conda-forge. We typically require adding full unit and acceptance tests, which can be a bit of a slog, especially on windows/osx.

A quicker path to getting something working for others might be to publish this as a standalone package on PyPI of just this spec, e.g. jupyterlab-lsp-go, which could be linked to from the docs on this site.

[joelschutz]

I'm not really sure on the best way to implement this support yet, the main question is how should the shadow files be managed. Heavy languages usually need a fair amount of boilerplate and the parsing between this very diferrent files needs some code to work.

A quicker path to getting something working for others might be to publish this as a standalone package on PyPI of just this spec, e.g. jupyterlab-lsp-go, which could be linked to from the docs on this site.

You say a fork jupyterlab-lsp, right? I have other changes that I'd need, so this is a good path to start development. Other thing that i'm thinking about is to create a wrapper around gopls to work with the currenty format. What do you think?

[bollwyvl]

You say a fork jupyterlab-lsp, right?

No, luckily that wouldn't be necessary, or good for anyone (go ask kite, and the users they convinced to install their fork).

The underlying jupyter-lsp server is extensible via the relatively-unique-to-python entry_points mechanism and/or Jupyter's "well-known" files, e.g. $PREFIX/share/jupyter/jupyter_server_config.d/jupyter-golsp.json... though, sadly, the JSON format isn't usually powerful enough to handle language server configuration.

So, with e.g. flit, you could get away with a structure like:

LICENSE
README.md
pyproject.toml
jupyter_golsp.py

Where the contents of jupyter_golsp.py contained the spec proposed on this PR (with absolute instead of relative imports), and advertised in pyproject.toml.

Of course, if you end up needing to do more (e.g. custom listeners, custom syntax highlighting in the browser), that structure would of course get more complex.

All this is to say: you're guaranteed to get something out faster published separately, rather than waiting for us to go through all the hoops. Having docs for this process would be great, too.

[krassowski]

@joelschutz are you still interested in driving this forward? I am happy to accept a PR, just needs to include tests as mentioned above.

[joelschutz]

I don't plan to keep working with this things in the near future, but I'd like to mention GoNB project by @janpfeifer that was able to incorporate completion using gopls in the kernel. I think he can help with this implementation.

[janpfeifer]

hi all, <pt-BR>e obrigado por me incluir Joel!</pt-BR>(thanks for looping me in).

So I'm wondering if the Python model will work for Go, or at least how GoNB works, since some assumptions work differently.

For instance GoNB compiles the whole Go code at every cell execution and memorizes definitions -- as opposed to "interpreting" it in a REPL loop. That works because Go compilation time is fast enough that it doesn't matter. But that has some implications, along with other considerations that I'll list below:

1. GoNB keeps a mapping of the line number in the assembled Go code (from all cells executed so far) to the cell ids (# of the execution) and their line number. There needs to be also a mapping of the cursor. GoNB keeps that to translate that to gopls. Something like this would need to be made for Go I suppose, since gopls expects a Go program, not independent cells -- there are more caveats here, but I won't get into the detail.
2. Usually the Go dependency/package system works super well, and imports "just work" without thinking about things like pip install libraries/packages. The occasional go import and automatically pulls things, and all just work. So GoNB does that automatically for the user, and gopls works with that. I think an embedded Go support in jupyterlab-lsp should also include this functionality, it's one of the big plus of using Go in my book at least.
3. Inform gopls of local files that are modified: both in Python and in Go, I often use Jupyter jointly developing some project, that includes separate libraries, in the local file. I'm not sure how the language server works in Python, but gopls needs to be informed that some of these libraries aren't to be pulled from github, but instead used from the local disk, and which directories to monitor for changes. A good integration definitely should support this, and GoNB does this magic for the user (see Developing Go libraries with a notebook in the tutorial).

Those are from the top of my mind, but it was tricky to get right, but it seems to be work in most (not all) times: Control+I for context help, or "shift+tab".

I'm not sure about the details of what you want to achieve in jupyterlab-lsp, but could it try to talk to GoNB, and through it get the LSP services you need ? If you tell me the features you would like to consider, we can define a new message and I'm happy to implement GoNB side of it -- we can even use custom messages to communicate if it makes sense to you, or something else -- I'm currently working on Widgets support for GoNB using these custom messages from the front-end, and it seems to be working great.

cheers