Re: Strategies for Composable Modular Configuration?

[Psionic K]

My rough sketch of a solution is a more strict subset of use-package
expressions that are merged by union.  Detect conflicts.  Support automatic
and hands-on resolution.  Track changes and notify the user when changes
are available.

If use-package were not eager and just collected declarations until the
user said, "Okay that's all my declarations, now execute the ones that
aren't no-op."  We would be free of the 1:1 correlation between use-package
expressions and packages configured for loading.

For configurations that are made across several packages, their declaration
would be untangled.  Can we do this now?  I don't know if some use of defer
enables this behavior, but I have never seen an example or evidence of
support for use in this way.

Composition, the calculation of one set on another set, I don't think is
necessary to do away with 80% of boring configuration, where the defaults
are at odds with what's popular among users.  Any composition will build on
top of things that are better for union aka superimposition, so union must
be supported before composition anyway.

If a users only agrees with 75% of the 80% of popular settings, they still
have only 40% of the configuration overhead.  This works in maintenance
because if changes made over time are only being rejected at a 25% rate,
the you end up doing 40% of the work, and most importantly, you would see
those changes as new conflicts rather than having to keep track of each
package's evolution.  The market rate can adjust to fit the ROI.  For
instance, if you agree with 99% of a small 20% of extremely unpopular
values, depending on them instead of setting and tracking them yourself is
almost a pure time save.

Regarding Flakes and ecosystem health, to understand the kinds of mistakes
that were being made by the uninitiated masses, you can't look at good
organizations, but instead must look at middling organizations and bad
organizations.  The free-for-all approach to creating expressions without
any structure lead to such oddities as operating Nix impurely and
articulating CI and even deployments.  It was a case of using something
within the limits of what worked, and there were no limits because it's a
programming language.  Flakes made these extreme misadventures obviously
wrong enough for them to stop happening.

Being strict about whether each symbol is loaded removes implicit
dependency, and then side-effects that are order-dependent don't rely on
flukes of the loading order and even user behavior to work every time.  The
subset of really nice use-package declarations users do already fits well
with the subset that is trivial to merge in union.

On Thu, Nov 23, 2023 at 8:19 PM Nikolay Kudryavtsev <
nikolay.kudryavtsev@gmail.com> wrote:

> I'm not sure that I fully understand what you're suggesting... I've been
> a casual Nixos user for years and even contribute from time to time, but
> nothing made me really care about flakes. So to try and explain this in
> a more practical manner, it's something like this:
>
> There's a portal lets say emacs-tweaks.gnu.org. It operates much the
> same way as a package repository, but the contents of it are not
> features(packages), but tweaks(flakes, pedals, whatever). The difference
> between a feature and a tweak is roughly that features implement new
> behavior, while tweaks just modify existing features to some requirement.
>
> Your definition of tweaks also does not allow for composition. Which
> means that most of them are limited to a single feature, which IMHO is
> not going to provide much ROI either. Because most of those tweaks are
> going to be isolated single variable tweaks and that's not where the
> problem lies. It's also not going to fully take over most of the
> configuration needs because you can't re-implement Spacemacs(on Doom,
> whatever) using such a limited system.
>
> Correct me if I misunderstood anything.
>
>

-- 

남백호
대표 겸 공동 창업자
포지트론