Extend beyond Flakes

[roberth]

Something I've been considering for a while.
Flakes serves flake-parts well, but there's untapped potential in what's currently called perSystem.

Concept and Terminology

Old perSystem

A very useful framing of this option, which is more broad, is:

module that constructs a possible world for some software to exist in

or more succinctly, a configuration of multiple things.
From the perspective of a thing (e.g. a package), this would be considered the environment, containing such things as build and host platform, and perhaps a small handful of choices that may or may not affect it.

Old toplevel

This doesn't mean that toplevel is going anywhere. It has earned a solid place as the location to define things that have already been subjected to the act of or never were subject of the act of to configure, and are instead the result of configuring: a configuration.

Concrete example: if you want your host to have one configuration, put it in toplevel. If you want your host to be cross compiled from potentially multiple build platforms, put it in whatever we'll call perSystem after this.

Babel

So we have a bunch of contention on the terms configure/configuration, which are far too similar for the very distinct usages proposed here.
It sure doesn't help that functions are often named for their result, so the confusion goes in all directions.
Brainstorming

Category 1
old toplevel, absolute space, configured, configuration, configurations, concrete, real, determined, definite

Category 2
configurable, configure, function, possible world, world, abstract, relative frame, platonic, undetermined

Implementation

Circumstance

• Currently largely flake-based ecosystem
• Very few changes could make perSystem usable outside the Flakes context
• A few more would make it first-class

Risks

• Things like inputs' are somewhat flakes-oriented.
  • Mitigation: make them opt-in, have module that configures flake-parts to behave more portably
  • Solution: achieve parity. inputs' is already a mechanism that solves a flaw in flakes, which is that these configurable spaces don't link together naturally except through the flawed ${system}
• Confusion.
  • Needs good docs
  • bring nix.parts online.

[vic]

Having (non-flakes-tied parts) nix.parts would be awesome <3.

Yes, I'd definitely love to be able to use flake-parts beyond flakes, mainly because many cool modules that currently exist and were created assuming flake-based idioms. For example, using devshells, nix-unit, treefmt and many other outside flakes would be a significant QOL improvement for stable-nix users and we'd avoid having to re-invent many wheels.

Definitely there's a gap and potential for having a perSystem-thing in outside flakes world.

Other perSystem implementations I've seen already, specifically for non-flake environments:

• froyo's `perTarget
• falake's `withSystem

Very few changes could make perSystem usable outside the Flakes context

I'm really happy to read this, if you feel like "few changes" could make flake-parts usable outside the flakes context, I believe it would be awesome if we could have an experimental branch we could try.

Just yesterday I was wondering what was required for flake-parts to be usable outside flakes. But you know the system better, and if you feel few changes (and some opt-in modules for things like inputs') could give us generic nix.parts that'd be awesome.

My plan to move away from flakes was the same as @drupol's (who devised and explored it first): using unflake to load flake-parts and hopefully have the same infra without much changes be usable in stable-nix. EDIT: I have a little demo showing flake-parts without flakes.

I'd certainly be happy to help make this possible.

[adrian-gierakowski]

Can't wait!

At work with have something similar to perSystem but which is called perEnv. We use it to configure the world for different environments like dev, staging, production. Is this a use case that could be catered to by what you have in mind?