bug#61637: 30.0.50; Fix Eglot tests that need HOME=~USER

[João Távora]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: João Távora <joaotavora@gmail.com>
>> Cc: contovob@tcd.ie,  61637@debbugs.gnu.org
>> Date: Sat, 04 Mar 2023 11:48:27 +0000
>> 
>> Eli Zaretskii <eliz@gnu.org> writes:
>> 
>> >> From: João Távora <joaotavora@gmail.com>
>> >> Cc: "Basil L. Contovounesios" <contovob@tcd.ie>,  61637@debbugs.gnu.org
>> >> Date: Sat, 04 Mar 2023 01:04:45 +0000
>> >> 
>> >> I installed some language servers like clangd, rust-analyzer and pylsp,
>> >> and they need to a valid HOME to be able to function.
>> >
>> > Please tell more about this: what exactly do these servers need from
>> > the home directory?
>> 
>> Every server is different.  This is the complain for a pylsp installed
>> with 'pip install pylsp' for the regular user, which you can find in the
>> output of e.g.
>> 
>>    make -C test lisp/progmodes/eglot-tests SELECTOR='"basic-completions"'
>> 
>> This are the relevant parts of the output.  Here, it looks like the
>> pylsp trampoline in ~/.local/bin/pylsp can't find the main supporing
>> library, which probably lives around the corner in
>> ~/.local/lib/python3.10/site-packages.
>
> Is it reasonable to have an LSP installed in the HOME directory when
> running the Emacs test suite, when we clearly document that HOME is
> ignored for these tests?

It's rather two questions from my perspective:

* Is there an easy way to install the pylsp server that _isn't_ this
  HOME directory installation so that Eglot devs can run the tests?
  There doesn't seem to be, at least not easy.  Furthermore I (and I
  suppose many others) prefer installing toolchains in unpriviliged
  places rather than priviliged system ones.

* If people do have this installed in HOME, it it reasonable to
  downright fail in their faces.

I think that, to be consistent with this HOME spoofing (which I find a
bit draconian in this case) then Emacs should also spoof PATH so that
these HOME programs aren't found in the first place.  

It comes down to what are the intended semantics of finding external
executable during Emacs 'make check'.  Only system-wide executables?
Should 'make check' chroot itself or something?  Should we be trying to
solve the very hard problems of determinism at all?  Shouldn't that be
left to a broader sandboxing solution, or a chrooting solution like
docker?

> How about if we ask users who install LSP servers under their home
> directory to somehow specify the exact location of that installation,
> so that the LSP will find its components, but Emacs won't access any
> files in the user's HOME via the "~" shortcut?

How do you propose we do that?  What users exactly?  Eglot-interested
devs?  What about the others working on libraries and trying not to
break things?  When should users do that specifying?  Isn't it different
for each server and each installation method?

>> > As I said, I don't like the idea of using the user's real home
>> > directory for test purposes.  We could end up clobbering precious
>> > files there.  We could also have tests fail because some user setting
>> > in the home directory makes the test results unpredictable.
>> 
>> As I understand it, the concern of cloberring user customizations is
>> mostly related to Emacs' own packages like ido or auto-save-mode, some
>> of them do write files in ~/.emacs.d and similar.  That is reasonable.
>> 
>> But this is different IMO.  We're talking about user-installed language
>> servers, which presumably these users are already using (because they
>> installed them).  Only for the specific invocations of these servers is
>> HOME spoofed.  Overall I think the risk is low.  Eglot has had these
>> types of tests since practically the beginning and I've never had
>> complains of clobbered files.
>
> You disregarded the second part of my reasoning, which has to do with
> the test results being non-deterministic once the user's real home
> directory is accessible to Emacs.  How do we overcome that?

Sorry I didn't mean to disregard, I just missed it.  Well, it's not
accessible to Emacs, only to LSP servers.  Eglot's tests are fairly are
deterministic, all other things like LSP server versions being equal.

I'd say Eglot's tests are even robust to any changes in LSP server's
user init files.  See how XDG_CONFIG_HOME is spooffed in eglot-tests.el
to this effect.  It has been effective AFAICT for some time.  And that's
only for those few servers that do offer these mechanisms: most of them
rely on project-local configurations which is fine because Eglot creates
a temporary project for each test.

All in all, I think the problem of user file clobbering and determinism
are exaggerated -- in this specific case of course.  They are secondary
to the fact that it's tricky, noisy, or even impossible to run Eglot
tests ever since Eglot moved to Emacs core.  

I propose we install my patch and then perfect the solution.  Again,
we're only affecting those devs who _do_ have these local installations,
and that affection is much, much more likely to be beneficial than
harmful.

João