Re: Stability of core packages (was: Not easy at all to upgrade :core packages like Eglot)

[João Távora]

On Thu, Apr 20, 2023 at 2:13 AM Dmitry Gutov <dmitry@gutov.dev> wrote:

> >> because the package can't be installed (no connection). Should they
> >> remove ":ensure t"? Perhaps. But the documentation says that that option
> >> checks that the package is "installed automatically if not already
> >> present on your system". Seems legit, right? Why would startup fail when
> >> Eglot is already present on the system?
> >
> > Because we want it to do the same it did in Emacs 28?  But I see what
> > you mean.  Maybe the :ensure for packages in that particular subclass
> > should mean "try a bit harder to upgrade these, but don't blow up if
> > you can't -- just try next time".
>
> ... maybe.

I just looked in straight.el.  I haven't actually tried it, but I noticed
that the only place where it cares about if a package is built-in or not is
in straight--convert-recipe.  And to my (pleasant?) surprise, it is using
it to decide whether to report an error or not if the package is not found.
If it's builtin, the error it not thrown.

> Maybe you'll put the recommended use-package form somewhere in the Eglot
> manual, right? It will be published on the web as well. Will it contain
> ":ensure t" or not? If not, the users of Emacs 28 might fail to get the
> package installed. If it will, then the offline users might have
> problems, as described previously.

To be honest, I'm thinking of either not recommending a package manager
at all, or just recommending a third-party one that I think rhymes
with what Eglot users expect.  Might very well be straight.el or
elpaca.el.  One things is for sure, my previous recommendation
of "use package.el" is not good.

> > to ElDoc and use it in Eglot in the same patch, etc.  That part
> > has worked fine.  It wasn't impossible with Eglot in GitHub, but
> > it was harder.  Hopefully Eli is not asking for that bliss to end
> > I understand hope he's asking to be circumspect in what
> > is added, and not do gratuitous things like bump dependencies
> > without reason.  I already do that, so no problem.
>
> It seems like most of this could have worked out if Eglot moved to the
> emacs.git repository, but was removed from the distro before packaging?
> Just a thought, not that I advocate for doing that.

Then emacs -Q bla.py -f eglot would not work.

And major modes in Emacs could not use eglot.el as a library.

> > Finally, if you're taking all this in the direction of "I told
> > you so, don't you regret bringing Eglot into Emacs 29?", I don't
> > blame you.  But I have to say: no, not yet.  I think having the
> > beginnings of an LSP library in Emacs for major-modes to work
> > with is excellent.  I like the attention and the high-standards
> > other seasoned developers hold my code up to.  I like the Info
> > manual and I like that emacs -Q bla.c -f eglot works just fine.
>
> I like my told-you-so's as much as the next guy (just kidding;
> definitely more than the next guy), but that's not the point I was
> making. Just that it's here now, and it seems odd to avoid using it and
> hurry up to install the next version right away.

I agree.  I don't want users to hurry, but I don't want them to not
hurry either :-).  It depends on what they want.  Eglot 1.12.29 in
Emacs 29 is pretty good.

> > This upgrade situation sucks, is true, and I should have foreseen
> > it.  Spent too much time in my emacs-master worktree I guess.
> >
> > Who knows, maybe this will all be OK after all?? Half the
> > users are using "straight.el" anyway (and I really doubt
> > it is hampered by these minutiae about dependencies, seeing
> > as MELPA-land is teeming with way more "dependency hell").
>
> I'm pretty sure the users on straight.el are straight-up illusion. It's
> the latest fashion on reddit all right, but it has its own problems, and
> the silent majority are still using the older methods.
>
> Not to say it's a bad project (I'll try to migrate my authored packages
> to it one day, since it seems to make that natural), but for an average
> user? I don't think so.

I don't know.  I see a lot of people using it, and have seen that
for a long time.  The average user googles things and lands on reddits
hits.  ChatGPT teaches you "straight.el" too (if you ask it).

> > If nothing more happens on Emacs 29, which is the most likely
> > outcome, I think I will just start recommending "straight.el"
> > more, maybe learn it myself.  I had problems with it in the
> > past but it's probably matured now.
>
> I would suggest to start recommending ways to perform an upgrade
> explicitly (somewhere in the README, in the manual, and so on). Like
> 'M-x package-upgrade', if we manage to get it fixed in Emacs 29.

That's a big if.  My worry here is how to clearly control this
messaging, especially when dealing with cleanly deterministic
bug reports.  I have to know exactly the version that he user
is running.  Recently, I've become adept at doing:

HOME=`mktemp -d` emacs -l recipe.el

It's a very good way to establish sanity.  And until now recipe.el
could have just `(package-install 'eglot)` and I would know exactly
what packages the user has installed.  The answer will now
be different in Emacs 28 vs Emacs 29.  Mind you, I will still
know, of course, but the thing installed on Emacs 28 will be
wildly different than the one installed on Emacs 29.  And,
as I said before and everybody understands, it will get worse with
time.  So what form to give users??

I suggested adding a 'eglot-update' function to eglot.el only --
the only code I normally have control over.  A four-line long function
that I would put it Emacs 29.  It would have this property of
being absolutely consistent in whatever Emacs you're on.
But Eli called it "the worst of all worlds" and flatly refused it.
Maybe he could reconsider, who knows, if all this writing that
has happened since has provided some more perspective about
the problems.

> And, okay, having a separate section in README about Emacs 29 might suck
> at first, but then the majority of the users move to it, and support
> will get easier, more uniform.

Yeah, I guess.  BTW the tea leaves and some comments in the Philip-Eli
interaction tell me that the behaviour is going to again be different in
Emacs 30.  That will suck for a longer time.

> That's the only hard breakage I managed to come up with. The others are
> of logical kind (functions and commands doing things somewhat against
> their documented behavior), but that's also not so great because people
> like their tools to make sense.
>
> To name an example: 'package-install' will upgrade Eglot even though
> (package-installed-p 'eglot) already returns t.

Even with today's patch in Emacs 29 that already happens if you tweak
the new "heavy-handed" variable.  So I guess that isn't a problem.

João