Not published in VSCode marketplace?

[danilofuchs]

I could not find the language server client in the marketplace (I'm sorry if this is my mistake and it is actually there, but I just couldn't find it!).

Building it manually is a huge entry barrier for anyone attempting to use this LS.
I work with VSCode daily in many different languages, and this is the only extension I had to clone the repo and build everything until I could get it to work, as opposed to VSCode's built-in single click install.

[tgingold]

There are several reasons why it is not published: it is still work in progress, and it requires the ghdl-ls binary. So even if you could install it with a click, it wouldn't work without downloading the binary.

I have to investigate how other projects deal with these constraints.

[eine]

To elaborate a bit further, ghdl-ls is tightly dependent on libghdl and the standard/ieee libs distributed as part of GHDL. Therefore, users cannot install any language server with any GHDL version. Moreover, there is no scheduled release scheme for GHDL and semver is not used. This makes it difficult to publish releases of the VSCode extension which include information about which GHDL versions are (in)compatible. Hence, the complexity is not to get the language server, but to distribute GHDL.

[danilofuchs]

I hope I can help you make some decisions:

it is still work in progress

Many extensions use a '(Preview)' tag to show it is still WIP. Visual Studio Live Share used to have this tag before general availability.

it requires the ghdl-ls binary. So even if you could install it with a click, it wouldn't work without downloading the binary

Other extensions, such as Python, automatically download and manage the language server. I believe it is safe to assume that an user that uses the extension will not use the language server on its own, or even know it exists, as what matters to him is taking advantage of code editor integration.

I have seen other extensions that simply show a popup with a link to binaries / dependencies, so the user can quickly solve any issues

Moreover, there is no scheduled release scheme for GHDL and semver is not used. This makes it difficult to publish releases of the VSCode extension which include information about which GHDL versions are (in)compatible. Hence, the complexity is not to get the language server, but to distribute GHDL

This indeed is a very big issue. How are you managing this compatibility issue right now in the language server?

If the extension managed the language server on its own (possibly installing it in a separate place, with dedicated ports for the extension, avoiding conflicts with other installations), it could be bundled with the extension, and when a new version is uploaded, a new compatible version for the server is introduced

[eine]

How are you managing this compatibility issue right now in the language server?

Currently, we are not managing it. master from this repo is expected to be compatible with master from ghdl/ghdl. If something changes in ghdl/ghdl, it is fixed here whenever. So, in order to release anything to the marketplace, a maintainer needs to take care of selecting compatible commits from ghdl/ghdl and from here. That's what distribution packagers do ATM. See ghdl/ghdl#1108.

EDIT

Also, there is a docker image in ghdl/docker which is updated/published periodically.

[tgingold]

A simple solution is to move ghdl-ls into the ghdl repo.

[eine]

A simple solution is to move ghdl-ls into the ghdl repo.

I think this is reasonable, given the small size of this project (the ls) and the tight dependency.

Still, users would need to compile and install GHDL on their own, which I think is what this issue was/is about.

[danilofuchs]

Agreed. Moving the LS to the main repo + adding a descriptive message in the VSCode plugin so users know what / how they have to install is a good option

[eine]

@danilofuchs, since this is experimental yet, you might want to have a look at rust_hdl. See jeremiah-c-leary/vhdl-style-guide#312 interesting.

[tgingold]

Now moved. I have (quickly) updated the READMEs, but I am pretty sure the docker images have to be updated too. I am not sure if 'make install' should also install the python part (ghdl-ls). Any hint ?

[eine]

• It seems that you moved the python server only. Are we going to keep this repo for the clients?
• What about ghdl-ls/tests? If those are tests for the server, they should be moved to ghdl/ghdl.
• NOTES? TODO?
• The previous README required the user to install libghdl-py. However, this requirement seems to be gone: 82381b7 . Is it because libghdl-py is not required by the language server? Or is libghdl-py installed by default along with libghdl?
• I think that section https://github.com/ghdl/ghdl-language-server#usage belongs to ghdl/ghdl (subdir python) now. Here, a reference should be added.
• I don't think the python part should be installed by default, but it might be desirable to distribute it along with the tarball. So, make install would copy python sources to a known location, but not install them system-wide.
• I will update docker images when I have a clear picture of the new structure.

EDIT

• attrs, which is a dependency of ghdl-ls, seems to be undefined now. See ea8db85#diff-348b3b8e95addec8cf074ddf99e5ee72L34 and https://github.com/ghdl/ghdl/blob/master/python/setup.py.

[tgingold]

• It seems that you moved the python server only. Are we going to keep this repo for the clients?

No, only the server will be moved.

• What about ghdl-ls/tests? If those are tests for the server, they should be moved to ghdl/ghdl.

Yes, at some points they will certainly be moved.

• NOTES? TODO?

I am not sure how them. The user entry point is ghdl-language-server, so I think this is the best place to document how to use it.

• The previous README required the user to install libghdl-py. However, this requirement seems to be gone: 82381b7 . Is it because libghdl-py is not required by the language server? Or is libghdl-py installed by default along with libghdl?

All the python files are installed together; so I think we could get rid of libghdl-py.

• I think that section https://github.com/ghdl/ghdl-language-server#usage belongs to ghdl/ghdl (subdir python) now. Here, a reference should be added.

I still prefer to let the documentation there.

• I don't think the python part should be installed by default, but it might be desirable to distribute it along with the tarball. So, make install would copy python sources to a known location, but not install them system-wide.

That makes sense for tarball, indeed.

• I will update docker images when I have a clear picture of the new structure.

Ok!

[eine]

All the python files are installed together; so I think we could get rid of libghdl-py.

That makes sense. For now, libghdl-py is only used by the language server. If some other project uses it in the future, it is possible to split them again.

• I think that section ghdl/ghdl-language-server#usage belongs to ghdl/ghdl (subdir python) now. Here, a reference should be added.
I still prefer to let the documentation there.

I think it would be cleaner if the docs and code for the clients were kept here, and the docs and code for the server were kept in ghdl/ghdl. Of course, references should be added between both READMEs. I believe that hdl-prj.json is the relevant part of the docs that belong to the server but is specially interesting for end-users. OTOH, we might elevate the configuration file to be supported by ghdl too, and thus move it to the docs site. What do you think?

• I will update docker images when I have a clear picture of the new structure.
Ok!

Done. It fails because of attrs, but otherwise it is all good.