bug#62694: 30.0.50; eglot-tests fails with recent pylsp

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

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

Hi João,

>> I don't doubt. But you cannot expect that everybody uses "the number one
>> recommended pylsp installation method".
>
> I expect that. The same way I expect people to install Eglot from ELPA, and
> use a normal installation of Emacs, not some "Doom" or "Spacemacs". Or the
> same way I expect people not to have advice in their configurations.
> Many times my expectation fails, and yet I expect these things, because
> that's what I programmed against.
>
> So if they don't use that method, then maybe they should.  More
> importantly, here we're  talking about the much smaller universe of Emacs
> developers, not regular users.

I don't speak about eglot (pylsp) users. They will know what to do.

I speak about ordinary Emacs users, not interested in eglot, who could
see Emacs errors when they run "make check". Just because eglot-tests.el
doesn't check its prerequisites sufficiently. As we have seen,
(skip-unless (executable-find "pylsp")) is not sufficient. 

>> Again, I'm not speaking about eglot users. They shall know what to
>> do. But eglot-tests could fail for everybody who has installed a pylsp
>> package, for example from Debian, w/o even being interested in eglot.
>
> That package is faulty to some degree in that it does not work exactly
> like the recommended installation of pylsp.

Likely yes. But people might have it installed, because they use
Debian. Why don't you check this wrong installation of pylsp in your
skip checks? This would solve it sufficiently, I believe.

> Even if that's a problem for some hypothetical hardcore Debian
> user who happens to also be an Emacs developer and who uses pylsp
> but not in Eglot, and for some reason won't install anything from anywhere
> else in his development machine, we have yet to hear from the hordes of
> users at the intersection of all those conditions.

The don't need to be pylsp users. A package could be installed for
several reasons.

And we haven't heart from them, because there doesn't exist an Emacs
release with built-in eglot and eglot-tests yet. People, who install
eglot from ELPA I don't care about, they know what they do.

> In your case in particular, I'd say you have control over what you
> install in your machine and what you install in EMBA.  And I've
> given you the recommended way to fix this, if you really must have
> pylsp there.  Again, can you answer what is preventing you from using
> `pip install` in your machine or in EMBA scripts?

The point is not Emba. It is just a mean to demonstrate what could
happen. And yes, I try to make the environment according to what people
use in general. And not to install special 3PP, not included in Debian,
just to "let the tests succeed". That's not the idea of regression tests.

> Also, what is moving you so resolutely to install pylsp at all in EMBA?
> Are you programming Python with some other LSP client on EMBA.  Is
> anyone?

No, I'm neither interested in python nor in eglot myself. I'm interested
in a stable Emacs. And I know, that people providing tests should ensure
that their tests do not harm. Yes, any failed test in the wild is a harm.

> Are you just trying to get the best possible coverage from eglot-tests.el?
> Thanks, but then I'd focus on rust-analyzer first, or the Java jdtls server.
> The latter would be really useful as the GitHub CI isn't currently
> installing it and the test is being skipped there.

If you could show me the Debian way to install rust-analyzer or jdtls in
Debian, I'm your man. I didn't find a corresponding package (but
honestly, I haven't tried for days). In case such packages don't exist
yet for Debian, I would be willing to install them differently, for a while.

>> > I don't have Debian.  We can overhaul the sanity checks, but I don't
>> > immediately see how.  Or why.  So it's hardly a priority.
>>
>> See above. With the instructions I have added to admin/notes/emba, it
>> should be simple.
>
> Thanks, I'll have a look one of these days.

Thanks.

> João

Best regards, Michael.