Re: eglot-tests fail for emacs-31 branch

João Távora <[email protected]> writes:

Hi João,

>> e2ff4dbf3db5 (Michael Albinus     2023-03-25  76)
>> 13a4cd5ed1ed (Michael Albinus     2025-06-08  77) RUN npm install -g typescript-language-server typescript
>> 13a4cd5ed1ed (Michael Albinus     2025-06-08  78) RUN npm install -g vscode-json-languageserver
>
> Anyway, I suggest changing that lines to
>
> RUN npm install -g [email protected] [email protected]
> RUN npm install -g [email protected]

Currently, with the instructions in Dockerfile.emba, we have

--8<---------------cut here---------------start------------->8---
root@11c96d5f8a34:/checkout# npm list -g
/usr/local/lib
+-- [email protected]
+-- [email protected]
`-- [email protected]
--8<---------------cut here---------------end--------------->8---

I've downgraded them as recommended:

--8<---------------cut here---------------start------------->8---
root@11c96d5f8a34:/checkout# npm uninstall -g typescript-language-server typescript
root@11c96d5f8a34:/checkout# npm uninstall -g vscode-json-languageserver
root@11c96d5f8a34:/checkout# npm install -g [email protected] [email protected]
root@11c96d5f8a34:/checkout# npm install -g [email protected]
root@11c96d5f8a34:/checkout# npm list -g
/usr/local/lib
+-- [email protected]
+-- [email protected]
`-- [email protected]
--8<---------------cut here---------------end--------------->8---

And now, running 'make -C test eglot-tests' passes all tests. Good.

>> However, pinning a given package version is not the solution.  On
>> emba, we try to run tests in a Debian environment an Emacs user will
>> see. If this doesn't work, we must fix it, or document what to do.
>
> I heartily disagree with you on this (philosophical?) point.  Probably
> one of the reasons we use Debian Trixie and not, say, a rolling-release
> Arch linux, is precisely that it always give us stable version of the
> software surrounding ours, so that the "fixed" in "fixture" can be
> upheld.  So if we use 'npm' in addition to 'apt' as a package
> installation aid, we must make sure it behaves like apt.

I would pretty much prefer apt over npm. But there are no respective apt
packages in Debian. There are only snap packages. And using snap doesn't
work in containers. See the comments in Dockerfile.emba about.

And even if it would be possible to use snap inside a container, it
would install the same versions like npm (tested with my Fedora 44
laptop):

--8<---------------cut here---------------start------------->8---
# snap install typescript-language-server
typescript-language-server 5.3.0 from Alex Murray (alexmurray✪) installed
# snap install vscode-json-languageserver
vscode-json-languageserver 1.3.4 from Alex Murray (alexmurray✪) installed
--8<---------------cut here---------------end--------------->8---

So yes, these versions of typescript-language-server and
vscode-json-languageserver should be supported. Emacs 31 users will see them.

> In practice, and concretely to the Eglot failure in question, I am more
> than happy if the signal is: "does Eglot currently work with _some known
> good version_ of typescript-language-server"?  That's because Eglot can
> be combined with so many other things, that I know with almost 100%
> certainty that, out there, there is some combination of language server
> + OS + myriad other thing that makes Eglot fail.

Sure, we can pin versions to be tested on emba. But that's a moving
target. I would appreciate if we could have this documented, at
least. Something like a comment in eglot.el, "tested with xxx language
server 123". And then we need to establish a policy, how these versions
can be changed over the time.

> Anyway, I'll see if I find the time to try these changes on my own, I
> started building a new podman emba thing yesterday but I'm rusty and it
> was taking a long while to compile, so I would be very thankful if you
> could try those `npm install -g` for me, interactively, in your
> up-to-date local emba and then re-run `make -C test eglot-tests`.

It works, see above.

> If they pass there's a good change that it's a good change to commit
> to the Dockerfile.

I will do once we have agreed how to handle this version pinning in general.

> If you don't agree, just remove those two lines altogether.  It'll fix
> the failures, of course (and I'll lose the signal, but that's not
> dramatic).  Up to you.

Now that we know it isn't a showstopper for Emacs 31.1, I can live with
this error for a while. And it would be great if you could find a
solution in eglot.el, or at least a condition for skipping the two tests
in eglot-tests.el. Emacs users will report about this error in the
future (I'm sure), and we should be happy that we can reproduc the error
locally. So we have a chance to fix.

> Thanks again,
> João

Best regards, Michael.