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

[João Távora]

On Thu, Apr 6, 2023 at 6:39 PM Michael Albinus <michael.albinus@gmx.de> wrote:
>
> 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".

But these Emacs users are _also_ pylsp users, who have the Debian
pylsp package installed.  So you _are_ speaking about pylsp users.

> >> 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.

How do I do that? How do I do that portably?

> > 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.

That could happen, but I doubt that pylsp is installed for any other
reason than to be used.  To intersect the set of people who have
installed it "accidentally" and additionally happen to be
"make check"-running Emacs devs who are completely baffled when
they see the failure.  Until I'm shown otherwise, I really think
you're the only person in that set in the world, and you're not baffled:
you know exactly what's going on.

> And we haven't heart from them, because there doesn't exist an Emacs
> release with built-in eglot and eglot-tests yet.

But Eglot with these tests has been in master for a very long time,
where Emacs dev happens.  And that's where people normally run
make check, not in a release they download.

In fact there were many more serious errors there for a long time that
didn't appear before you installed clangd on EMBA. And clangd is orders
of magnitude more popular than pylsp.

By the way, remember when your clangd installed via Debian's snap
or something was a  senseless do-nothing script?  Should I also ironclad
eglot-tests.el against that?

> 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.

You've demonstrated an academic possibility.  A lot of things in
this world may conceivably happen but are extremely rare or have
never happened.

> 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.

Here the 3rd party _is_ Debian's packaging!  Just use pip:

  Pip is a package-management system written in Python and is
  used to install and manage software packages.    The Python
  Software     Foundation recommends using pip for installing
  Python applications and its dependencies during deployment.

It's as kosher as it gets!  I don't recommend Debian packages for
installing Emacs packages, I recommend package.el, which is under
our control.  Have you at least tried pip there?  Can you at least
relay back if it works?

> 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.

Put on your boots and your hat, go into the wilderness and bring me some
of these wild creatures.

Frankly, this obstinate stance about Debian's package manager, just
makes people want to _not_ contribute tests.

> > 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.

What is with this blind devotion to Debian?  It's a nice distro, but
surely it can handle installation of software in different ways.

João