Re: Stability of core packages

[Corwin Brust]

On Sat, Apr 29, 2023 at 4:47 PM Mohsen BANAN
<emacs@mohsen.1.banan.byname.net> wrote:
>
> >> This is what doomemacs does. For every package,
> >> there is a git tag which doomemacs keeps with the
> >> adoption of the package. The tags are guaranteed
> >> to be consistent. With Blee (ByStar Libre Emacs
> >> Environment) I do the same but instead of keeping
> >> that tag with the packages, I keep central
> >> manifests for emacs releases. So, emacs-28.1 has
> >> its own packages manifest which can be upgraded
> >> from time to time. All upgrades go to the
> >> appropriate repo and get the appropriate tag based
> >> on the manifest. I do this across all emacs
> >> package archives -- which I see as collections of
> >> git repositories.
> >>
> >> If you want to go with something like this, you
> >> have to revisit the package retrieval model.

[SNIP]

> -----------
> Why does Doom use straight.el and not package.el?
>
> package.el simply doesn’t cut it. Its flaws become
> apparent the more packages you manage, the more
> complex your config becomes, and how often those
> packages see updates:

This is the same doomemacs project[1] that does all development
against HEAD of master, correct?    I track three Emacs branches, all
of which see frequent pushes. Work is regularly merged back to trunk.
I don't see anything like this level of practice maturity from doom
(or straight), so I think the lesson here isn't technical, but
something more like:

1. For powerusers, package.el isn't better than manually tracking
package versions.
2. Tracking package versions is so difficult that Emacs
re-distributers find it worthwhile to hard-code working combinations.

I think the issue is the packaging landscape has matured significantly
thus it is time to reconsider the uses-cases Emacs should support -
and that's the point of this thread.

Meanwhile, I think the practical upshot of the approach taken by doom
(and straight.el, in general) is to push tracking what versions of
which packages work together to individual uses.  I feel it would be a
step backward for Emacs to adopt this approach as the default,
expecting all users to learn to do it.  User-managed explicit package
version pinning does seem like a cool thing to support -- I hope
package-vc helps pave the way for core support for that use-case.  But
it should not be the default: I would be sad if we decide to expect
new users to master package pinning to try out new features.

[1] https://github.com/doomemacs/doomemacs/branches