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

["João Távora" <joaotavora@gmail.com>]

On Thu, Apr 20, 2023 at 12:25 AM Dmitry Gutov <dmitry@gutov.dev> wrote:
>
>
> Anyway, adding it back and replying with a full quote.

Thanks, I also didn't notice emacs-devel was lost there.

> On 20/04/2023 01:49, João Távora wrote:
> What kind of semantics do we get with it?

The closest possible to Emacs 28 for _all_ users (Eglot users and
the Emacs users that are vulnerable to furtive upgrades and which
Eli is thinking of)

> 1. (use-package eglot :ensure t) considers select builtin packages to be
> "not installed" for the purposes of ":ensure t".
> 2. 'M-x package-install' allows installing them. It doesn't allow
> installing any other package for which (package-installed-p 'xxx)
> returns t, but allows installing (essentially upgrading) these ones
> (either just eglot, or both eglot and use-package).
> 3. 'M-x package-update RET eglot RET' still doesn't work unless eglot
> has been "upgraded" at least once via other means.
>
> Is that logical? Is even just 1+2 logical?

Neither is.  IMO we have to think in terms of expectations for each
package, not in terms of a heavy handed blunt class o packages like
"builtin".  Because Eglot wasn't a builtin and now is.  So this is
why my patch includes that predicate `package--safely-upgradeable-builtin`
The name is not good, I admit.  It should be
`package--hitherto-casually-upgradeable-builtin` maybe.

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

> Or, to put it another way, why did we decide to bundle Eglot with Emacs
> if the first thing we're going to do is to try to download it anyway?

Who is "we"?  I know for a fact some people are.  The enthusiasts are,
the feature seekers, are immediately.  Others will experiment, I
assume.  Very often one experimentation that happens is you just
save all your .emacs.d to the side safely and let er rip with
whatever init.el someone (trustworthy presumably) gave you.

( What, you're going to say you've never tried the spacemacs
  or doom emacs or nano emacs just to see what all the hype
  is about??? :-) )

But others, like me from time to time when working on VMs via ssh
machines,  will be very happy with sudo apt install emacs in
said machines (if not done so already) and use a vanilla
configurationless emacs.  And if you add a "clangd" to that
invocation and Emacs happens to be 29 you'll have nice LSP
for the first time in many years.  Personally, for _my_ quick
hacks in those situations, I don't bother with M-x package-install
latest-and-greatest, just as I don't bother bringing my heavy
config via ssh to that machine.  I can't really, I'm frequently
tmate'ing with other people there, we have to settle on Emacs -Q
(+ electric-pair-mode and a few obvious others).

But your question also has a completely different answer:
A very good reason I wanted Eglot to be bundled with Emacs is now
actually being put into question in this very thread.  I wanted
to simplify Eglot's development as it advances with other :core
packages.  For example, I wanted to split off its external
completion style easily into a separate core package, as I did
with Stefan earlier this year.  I want to be able to add a feature
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.

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.

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

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.

> So... I understand the problem, but I think we shouldn't change the
> functions in a way that makes them conflict with documentation or with
> each other.

Does the latest patch introduce any such conflict besides the
"no internet" case you mentioned?  Not that it's really a
conflict IMO: it's just what Emacs 28 did with Eglot AFAICT.

João