Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Allow usage selection of yang-language-server from $PATH or unpacked directory #91

Open
esmasth opened this issue Apr 6, 2024 · 4 comments

Comments

@esmasth
Copy link
Contributor

esmasth commented Apr 6, 2024

It would be beneficial for users to be able to select later revisions of yang-lsp yang-language-server, in case there is a gap in release of yang-vscode or users wish to stay on an older version of yang-language-server.

@dhuebner
Copy link
Member

@esmasth
I think the vs-code option "install another version" would do the same. Or do you have something else in mind?

Bildschirmfoto 2024-04-17 um 09 28 02

@esmasth
Copy link
Contributor Author

esmasth commented Apr 17, 2024

@dhuebner it was rather for even the latest and greatest Yangster/yang-vscode extension to use an unreleased (new/development) yang-lsp/yang-language-server as one use case, and to use an older yang-language-server with latest yang-vscode for some reason (bug/test) as we should not lose any improvements in the VS code extension side.

@dhuebner
Copy link
Member

@esmasth
I can understand that it is easier to test new yang-lsp for advance users, but it is really too complicated and error prone for the other users.
E.g. the user needs to know which yang-lsp is compatible with which yang-vscode version (it should then also be documented). Then the user need to know where to get other version of yang-lsp and so on.
For testing, and maybe redistributing, of a custom yang-lsp/yang-vs-code you can still build a version you like from the source code here and share a *.vsix file.

@esmasth
Copy link
Contributor Author

esmasth commented Apr 19, 2024

@dhuebner to ease the approach for what you suggest, may the *.vsix file be generated as part of build and release tasks?

Anyhow, given that the LSP language servers are supposed to be independent of the LSP client implementations based on the protocol handling, wouldn't it be reasonable to presume that interoperability is not at risk since the legwork of protocol handling is rather borne by the LSP client libraries and not the code here?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants