You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Currently, a flake has projectConfigurations.${system}, which provides many utilities for a flake, but all necessarily dependent on system.
Ideally, you would be able to extract overlays, schemas, and other things that are system-independent from a project configuration.
The configuration constructor could perhaps be provided a map of systems to package sets, then internally handle providing the per-system attributes. Something like:
I think the trickier part is the modules – maybe modules have to be partitioned into ones that don’t have access to pkgs and ones that do (ones that do can reference ones that don’t, but not vice-versa). But annoying to have to split things along this dimension, especially for modules that define options, where we don’t want to have to split, say, the treefmt module into two separate ones.
Alternatively, maybe we don’t provide pkgs to the configuration constructor at all, but let that be passed later somehow:
{outputs={flake-utils,nixpkgs,project-manager,self}: letsupportedSystems=["aarch64-darwin""x86_64-linux"];in{projectConfigurations=project-manager.lib.defaultConfiguration{inheritself;};overlays=self.projectConfigurations.overlays;}//flake-utils.lib.eachSystemsupportedSystems(system: letpkgs=importnixpkgs{inheritsystem;};in{# This now extracts `system` from pkgschecks=self.projectConfigurations.checkspkgs;});};}
Modules may now be called without a pkgs value in some cases, so modules need to conditionalize on that, like
Currently, a flake has
projectConfigurations.${system}
, which provides many utilities for a flake, but all necessarily dependent onsystem
.Ideally, you would be able to extract overlays, schemas, and other things that are system-independent from a project configuration.
The configuration constructor could perhaps be provided a map of systems to package sets, then internally handle providing the per-system attributes. Something like:
I think the trickier part is the modules – maybe modules have to be partitioned into ones that don’t have access to pkgs and ones that do (ones that do can reference ones that don’t, but not vice-versa). But annoying to have to split things along this dimension, especially for modules that define options, where we don’t want to have to split, say, the
treefmt
module into two separate ones.Alternatively, maybe we don’t provide
pkgs
to the configuration constructor at all, but let that be passed later somehow:Modules may now be called without a
pkgs
value in some cases, so modules need to conditionalize on that, likeAnd configuration modules need to do this as well in some cases.
The text was updated successfully, but these errors were encountered: