Factor out defaultSystems (→ systems) & allSystems to flake input#84
Factor out defaultSystems (→ systems) & allSystems to flake input#84bb010g wants to merge 5 commits intonumtide:mainfrom
defaultSystems (→ systems) & allSystems to flake input#84Conversation
ec11d84 to
fe93274
Compare
|
Any thoughts / concerns about this concept and/or implementation? |
zimbatm
left a comment
There was a problem hiding this comment.
Thanks, it took me a minute to get it. It's an interesting idea. It introduces a new pattern:
Instead of exposing allSystems and defaultSystems, have a single overridable systems input. The systems key would become a new convention to all flakes; if exposed, it allows you to control the systems with which the flake will be built.
If you agree with this convention then let's deprecate allSystems. Users can use nixpkgs.lib.platforms.all. And map defaultSystem to the systems input. Having only one extra input also helps keep the lock files small.
This is a new convention that lets consumers of the flake control what systems this flake will be built with. As a consumer you can pass your own list of systems, by overriding the inputs. Eg: ``` inputs.systems.url = "path:./flake.systems.nix"; inputs.systems.flake = false; inputs.treefmt.url = "github:numtide/treefmt"; inputs.treefmt.inputs.follows.systems = "systems"; ``` Invented with the help of bb010g in numtide/flake-utils#84
|
As long as changing EDIT: Removing |
|
I tried the |
This is a new convention that lets consumers of the flake control what systems this flake will be built with. As a consumer you can pass your own list of systems, by overriding the inputs. Eg: ``` inputs.systems.url = "path:./flake.systems.nix"; inputs.systems.flake = false; inputs.treefmt.url = "github:numtide/treefmt"; inputs.treefmt.inputs.follows.systems = "systems"; ``` Invented with the help of bb010g in numtide/flake-utils#84
This is a new convention that lets consumers of the flake control what systems this flake will be built with. As a consumer you can pass your own list of systems, by overriding the inputs. Eg: ``` inputs.systems.url = "path:./flake.systems.nix"; inputs.systems.flake = false; inputs.treefmt.url = "github:numtide/treefmt"; inputs.treefmt.inputs.follows.systems = "systems"; ``` Invented with the help of bb010g in numtide/flake-utils#84
|
Sorry, I meant only expose a single input called |
|
What do you want to do about |
|
I would keep all the library functions as is. allSystems is not overridable, but that's fine; I don't think people are really using it. If it's unclear, push the previous version and I will do the changes. |
|
Alright, dropped all of the breaking renames (all but |
defaultSystems & allSystems to flake inputsdefaultSystems (→ systems) & allSystems to flake inputs
This is an intermediary commit to help Git track file renames.
`./default.nix` provides backwards-compatibility.
A deprecated alias remains for backwards compatibility.
80ef2a7 to
c36a58b
Compare
defaultSystems (→ systems) & allSystems to flake inputsdefaultSystems (→ systems) & allSystems to flake input
|
Alright, reorganized and cleaned up using your ideas from numtide/treefmt#228 and https://github.com/zimbatm/exp-flake-systems. |
This flake input is overridable by downstreams and can be nicely propagated throughout dependency trees via `follows`.
This is a new convention that lets consumers of the flake control what systems this flake will be built with. As a consumer you can pass your own list of systems, by overriding the inputs. Eg: ``` inputs.systems.url = "path:./flake.systems.nix"; inputs.systems.flake = false; inputs.treefmt.url = "github:numtide/treefmt"; inputs.treefmt.inputs.follows.systems = "systems"; ``` Invented with the help of bb010g in numtide/flake-utils#84 See <https://github.com/nix-systems/nix-systems>
This PR is a back-compatible subset of #84. By adding a new flake input here, it makes it possible to override the list of systems using flake overrides. See <https://github.com/nix-systems/nix-systems> for the full explanation.
This PR is a back-compatible subset of #84. By adding a new flake input here, it makes it possible to override the list of systems using flake overrides. See <https://github.com/nix-systems/nix-systems> for the full explanation.
|
thanks for your help! #93 introduces what I had in mind, I hope you won't mind me closing this PR |
This patch set allows for easy overriding of systems lists downstream via flake inputs, in a library-agnostic way. Ideally, all flakes that consume systems lists will avoid hard-coding them and instead consume them via flake inputs, allowing systems to be robustly introduced to or removed from evaluation. Flake inputs consisting of these pure, plain Nix source files should be the lowest-common denominator for systems list concerns.
Compatibility with existing direct access of
default.nixis maintained. If that interface is not stable, then the introduction oflib.nixcan be eliminated.The
defaultSystemsinput in flake-utils is the same as thesystemsinput in https://github.com/divnix/nosys.