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

[Eli Zaretskii <eliz@gnu.org>]

> From: João Távora <joaotavora@gmail.com>
> Date: Fri, 7 Apr 2023 12:06:46 +0100
> Cc: michael.albinus@gmx.de, 62694@debbugs.gnu.org
> 
> > The problem does exist, as Micheal has explained in so many words.
> > Please trust him, as I do, that he knows what he is talking about, and
> > would have solved this himself if an easier solution were possible.
> >
> > I see no significant complexity in adding a version test.  We do that
> > in umpteen other places with many other programs.
> 
> It's not a version test. I've already done that for clangd, per Michael's
> request.  Here, pylsp's Debian packaging seems just to be buggy.
> 
> Michael has previously found another buggy way to install clangd for
> example, some method that created a 'clangd' script that didn't
> even respond to `--version`.  Those things are very hard to check against
> and it's just not worth it.

A version test doesn't have to mean literally testing the version.  It
can be a different test, specifically for the problematic behavior.
If we understand the problematic behavior, we can test for it.  (If we
don't understand the problem, how do we know it is in the server and
not in Eglot or elsewhere in Emacs?)

> > > I don't understand what the problem with adding a 'pip install' line
> > > to the EMBA scripts is.
> >
> > Again, please trust Michael on that one.  We will not make any
> > progress if we start second-guessing every request and decision of our
> > peers, especially after you already suggested the upgrade, and Michael
> > already explained why he thought it wasn't the best alternative.
> 
> No he didn't.  He _didn't_ explain what bad thing would come to the
> world if pip install was added to the EMBA scripts.
> 
> Alternatively, simply don't install any pylsp on EMBA.  Boom, also
> problem solved. Eventually, I will rework those tests to not rely on
> pylsp at all, and I'll use something else to test those parts of eglot.el
> 
> But spending time answering these mails doesn't make any progress in
> that direction.

Well, how about coding the test Michael asked, and I seconded, then?
I agree that it will be a much better use of our time than keeping
arguing about it.

TIA