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

[Dmitry Gutov <dmitry@gutov.dev>]

On 20/04/2023 04:49, João Távora wrote:

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

I've had problems reported because of outdated straight recipes on 
users' machines. It seems like a fine tool for a hacker, though.

>> 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??

If we go for the pinning approach, as Jim suggested, and the fix for 
that one makes it in in time, the form could like like

   (use-package eglot :ensure t :pin gnu)

and hopefully work across 28, 29 and later.

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

I'm not sure I like that one either.