Re: Stability of core packages

[Mohsen BANAN <emacs@mohsen.1.banan.byname.net>]

Corwin Brust <corwin@bru.st> writes:

> On Sat, Apr 29, 2023 at 4:47 PM Mohsen BANAN
> <emacs@mohsen.1.banan.byname.net> wrote:
>> ...
>> >> 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.

My mentioning doomemacs was not an endorsement of
doomemacs ...

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

Exactly.

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

That is not what I am saying or suggesting.

Over the past several years, we have learned
various things from:

 1) the packaging landscape
 2) package archive providers
 3) Emacs re-distributers

Right now, in practice, Emacs re-distributers
maintain the stable manifest of the matching sets
for each release of emacs.

I am suggesting two things:

1) package.el should evolve or be replaced with
   something that is the equivalent of
   straight.el.

2) The responsibility for maintaining a stable
matching set of packages for each release of emacs
should come down to package archive providers (not
the Emacs re-distributers). Package archive
providers should maintain stable and consistent
manifests. Emacs re-distributers and emacs
end-users can selectively overwrite these, but
that won't be the default.

The challenge here is that in the existing emacs
ecosystem, basic emacs (emacs+elpa), package
archive providers and emacs re-distributers have
no structure to facilitate convergence.

If basic emacs (emacs+elpa) could solve this
properly, the rest could have a pattern to
emulate. For that to happen, basic emacs needs to
learn the lessons of emacs re-distributers. That
was why I mentioned that experimenting with
straight.el is a good idea. Not as a capability,
but as a basis for existing policies and
practices.

...Mohsen