Re: Eglot tests on EMBA

[Michael Albinus <michael.albinus@gmx.de>]

João Távora <joaotavora@gmail.com> writes:

Hi João,

>> I'm not happy with this. EMBA installs a conservative list of software;
>> they shall be available as Debian bullseye package.
>
> Then you should complain to Debian and uninstall pylsp on EMBA is the
> meantime.

Nothing to complain to Debian. They offer pylsp in the testing version;
we have simply decided not to use it. We use the stable version.

>> Since Debian bullseye does not offer the package python3-pylsp (which
>> will be available with a later Debian release), I install on EMBA
>> python3-pyls. This shall be sufficient, because (according to
>> eglot-server-programs) "pyls" is supported.
>>
>> eglot-tests.el does not dertect this, it checks only for "pylsp". I
>> believe this shall be changed,
>
> No, it shan't :-) I'm not even sure how to do so portably.

The most simple way would be

--8<---------------cut here---------------start------------->8---
(skip-unless (or (executable-find "pylsp") (executable-find "pyls")))
--8<---------------cut here---------------end--------------->8---

But this is a sledge hammer approach I guess.

> Just undo your installation of pylsp on EMBA and I'll look
> into replacing that test with some other language server.
>
> Or run `pip install "python-lsp-server[all]"` in the dockerfile.
>
> Let's not overcomplicate eglot-tests.el with these things.

eglot-tests.el run for your environment. But there are people with other
environments (like Debian stable), which could errors running
eglot-tests.el.

>> the check shall be for all alternatives
>> configured in eglot-server-programs. And not only for python, but also
>> for other languages.
>
> No, that's an immense amount of work and that's not what these
> tests are really for.  People add stuff to eglot-server-programs
> liberally: it's a huge database now. I'm not crazy about that but
> is has always been the most  fair practice to acommodate server
> preferences, and people seem like to see their favourite server at
> least represented  there.

Is it that hard to extract all relevant server executables for a given
major-mode, and iterate over them with executable-find?

> But some of these servers don't work, are deprecated, have
> inconsistent executable names on different platforms: it's
> a mess.  Testing that is way beyond the scope of eglot-tests.el.

In such a case, the test shall fail. And that would be OK, by this you
get feedback what doesn't work (given people write bug reports).

> You may lobby for a eglot-server-program-tests.el instead,
> and I won't oppose it, but I personally don't have time for that,
> nor do I see a lot of value at the moment.
>
> eglot-tests.el is testing the server-agnostic Elisp logic in
> eglot.el -- Eglot _is_ server agnostic.  We just happen to need
> someone speaking LSP to be able to exercise features.  We could just
> as well have a (compliant) Elisp LSP server simulator and not worry
> about  external language servers in eglot-tests.el at all.  But that's quite
> a bit of work.  So some common installations of language servers are needed.

Sure, possible. I was just speaking about the given state of eglot-tests.el.

> `clangd` seems to be a fairly reliable one so I've been looking
> at transferring most of the tests that I can to clangd.  But it
> doesn't exercise _all_ the features that Eglot supports, like
> file watching.
>
> I'll look into adapting this test for clangd instead of pylsp.

OK.

> In the meantime, just uninstall python-lsp-server on EMBA and
> let this test be skipped for now.  Or install it like I suggested.

Will do.

Best regards, Michael.