[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Stability of core packages
From: |
Mohsen BANAN |
Subject: |
Re: Stability of core packages |
Date: |
Sat, 06 May 2023 22:58:38 -0700 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/28.1.50 (gnu/linux) |
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