search

non-Jedi / eglot-jl

Wrapper for using Julia LanguageServer.jl with emacs eglot
Creative Commons Zero v1.0 Universal
62 stars 11 forks source link

Manifest.toml #19

Closed gdkrmr closed 3 years ago

gdkrmr commented 3 years ago

I want to get rid of the submodules in the lsp-julia repository and wonder if it is enough to distribute only Project.toml or if I should also distribute Manifest.toml? And: Does it make sense to give the user some control over updating the Julia Languageserver?

ffevotte commented 3 years ago

I'm sure @non-Jedi has insightful comments to make about this, but here are my two cents:

I want to get rid of the submodules in the lsp-julia repository and wonder if it is enough to distribute only Project.toml or if I should also distribute Manifest.toml?

My (personal) opinion about this is that distributing the Manifest.toml is useful in order to prevent external changes in LanguageServer to potentially break eglot-jl for some users (but not all, depending on when their project/environment gets instantiated). Such situations can lead to very difficult to debug issues.

I think distributing the manifest for "applications" (as opposed to packages/libraries) is also in line with "official" best practices, and the choice that has been made by the VScode extension.

One more thought: distributing the manifest also means that the Language Server version to be used is part of the emacs package. This in turn means that users of MELPA (and possibly other emacs package managers) only have to worry about updating their emacs packages, and the julia environment gets updated at the same time. The obvious downside is that a new release of eglot-jl/lsp-julia has to be published for users to benefit from a newer version of the Language Server. In order to avoid this, lsp-julia (or eglot-jl) would not only have to stop distributing a manifest, but would also need to provide a convenient command for users to Pkg.update() their Language Server environment. Which means more feature to provide in the emacs package, and more issues for users to be concerned about. So I'm not sure the trade-off would be worth it...

Does it make sense to give the user some control over updating the Julia Languageserver?

eglot-jl has an eglot-jl-language-server-project customization variable that allows users to customize the environment they want to run the Language Server in. I'm not sure how many users actually use it, but at least it's very convenient to have such an option to try things when developing eglot-jl itself. Such an option is also useful for users who'd want to always use a bleeding-edge version of the Language Server.

gdkrmr commented 3 years ago

thank you for your comment, it is really helpful. I found keeping all the submodules up to date very tedious, the other extreme (i.e. only distributing Project.toml) also doesn't seem the way to go.

non-Jedi commented 3 years ago

I more or less agree with everything @ffevotte said above. :)