1
0
Fork 0
mirror of https://github.com/LnL7/nix-darwin.git synced 2024-12-15 17:51:01 +00:00
nix-darwin/flake.nix

86 lines
2.7 KiB
Nix
Raw Normal View History

2020-10-18 10:46:59 +00:00
{
# WARNING this is very much still experimental.
description = "A collection of darwin modules";
outputs = { self, nixpkgs }: let
forAllSystems = nixpkgs.lib.genAttrs [ "aarch64-darwin" "x86_64-darwin" ];
in {
2020-10-18 10:46:59 +00:00
lib = {
eval-config: rationalize handling of Nixpkgs This is a big change that disentangles a lot of mistaken assumptions about mixing multiple versions of Nixpkgs, treating external flake inputs as gospel for the source of Nixpkgs and nix-darwin, etc.; the end result should be much simpler conceptually, but it will be a breaking change for anyone using `eval-config.nix` directly. Hopefully that shouldn't be a big issue, as it is more of an internal API and it's quite likely that existing uses may have been broken in the same way the internal ones were. It was previously easy to get into a state where your `lib` comes from nix-darwin's `nixpkgs` input or a global channel and your `pkgs` comes from another major version of Nixpkgs. This is pretty fundamentally broken due to the coupling of `pkgs` to its corresponding `lib`, but the brokenness was hidden much of the time until something surfaced it. Now there is exactly one mandatory `lib` input to system evaluation, and the handling of various additional options like `pkgs` and `system` can be done modularly; maintaining backwards compatibility with the previous calling convention is punted to the `default.nix` and `lib.darwinSystem` entry points. `inputs` is no longer read by nix-darwin or special in any way, merely a convention for user code, and the argument is retained in the entry points only for backwards compatibility. All correct invocations of the entry points should keep working after this change, and some previously-broken ones should be fixed too. The documentation and template have been adjusted to show the newly-recommended modular way of specifying various things, but no deprecation warnings have been introduced yet by this change. There is one potential, mostly cosmetic regression: `system.nixpkgsRevision` and related options are less likely to be set than before, in cases where it is not possible to determine the origin of the package set. Setting `nixpkgs.source` explicitly will make this work again, and I hope to look into sending changes upstream to Nixpkgs to make `lib.trivial.revisionWithDefault` behave properly under flakes, which would fix this regression and potentially allow reducing some of the complexity. Fixes: #669
2023-07-07 08:02:38 +00:00
evalConfig = import ./eval-config.nix;
darwinSystem = args@{ modules, ... }: self.lib.evalConfig (
{ inherit (nixpkgs) lib; }
// nixpkgs.lib.optionalAttrs (args ? pkgs) { inherit (args.pkgs) lib; }
// builtins.removeAttrs args [ "system" "pkgs" "inputs" ]
// {
modules = modules
++ nixpkgs.lib.optional (args ? pkgs) ({ lib, ... }: {
_module.args.pkgs = lib.mkForce args.pkgs;
})
# Backwards compatibility shim; TODO: warn?
++ nixpkgs.lib.optional (args ? system) ({ lib, ... }: {
nixpkgs.system = lib.mkDefault args.system;
})
# Backwards compatibility shim; TODO: warn?
++ nixpkgs.lib.optional (args ? inputs) {
_module.args.inputs = args.inputs;
}
++ [ ({ lib, ... }: {
nixpkgs.source = lib.mkDefault nixpkgs;
system.checks.verifyNixPath = lib.mkDefault false;
2023-07-01 15:11:16 +00:00
system.darwinVersionSuffix = ".${self.shortRev or self.dirtyShortRev or "dirty"}";
system.darwinRevision = let
rev = self.rev or self.dirtyRev or null;
in
lib.mkIf (rev != null) rev;
eval-config: rationalize handling of Nixpkgs This is a big change that disentangles a lot of mistaken assumptions about mixing multiple versions of Nixpkgs, treating external flake inputs as gospel for the source of Nixpkgs and nix-darwin, etc.; the end result should be much simpler conceptually, but it will be a breaking change for anyone using `eval-config.nix` directly. Hopefully that shouldn't be a big issue, as it is more of an internal API and it's quite likely that existing uses may have been broken in the same way the internal ones were. It was previously easy to get into a state where your `lib` comes from nix-darwin's `nixpkgs` input or a global channel and your `pkgs` comes from another major version of Nixpkgs. This is pretty fundamentally broken due to the coupling of `pkgs` to its corresponding `lib`, but the brokenness was hidden much of the time until something surfaced it. Now there is exactly one mandatory `lib` input to system evaluation, and the handling of various additional options like `pkgs` and `system` can be done modularly; maintaining backwards compatibility with the previous calling convention is punted to the `default.nix` and `lib.darwinSystem` entry points. `inputs` is no longer read by nix-darwin or special in any way, merely a convention for user code, and the argument is retained in the entry points only for backwards compatibility. All correct invocations of the entry points should keep working after this change, and some previously-broken ones should be fixed too. The documentation and template have been adjusted to show the newly-recommended modular way of specifying various things, but no deprecation warnings have been introduced yet by this change. There is one potential, mostly cosmetic regression: `system.nixpkgsRevision` and related options are less likely to be set than before, in cases where it is not possible to determine the origin of the package set. Setting `nixpkgs.source` explicitly will make this work again, and I hope to look into sending changes upstream to Nixpkgs to make `lib.trivial.revisionWithDefault` behave properly under flakes, which would fix this regression and potentially allow reducing some of the complexity. Fixes: #669
2023-07-07 08:02:38 +00:00
}) ];
});
2020-10-18 10:46:59 +00:00
};
overlays.default = final: prev: {
2023-07-01 15:11:16 +00:00
inherit (prev.callPackage ./pkgs/nix-tools { }) darwin-rebuild darwin-option darwin-version;
darwin-uninstaller = prev.callPackage ./pkgs/darwin-uninstaller { };
};
darwinModules.hydra = ./modules/examples/hydra.nix;
darwinModules.lnl = ./modules/examples/lnl.nix;
darwinModules.ofborg = ./modules/examples/ofborg.nix;
darwinModules.simple = ./modules/examples/simple.nix;
2020-10-18 10:46:59 +00:00
templates.default = {
path = ./modules/examples/flake;
description = "nix flake init -t nix-darwin";
};
checks = forAllSystems (system: let
simple = self.lib.darwinSystem {
eval-config: rationalize handling of Nixpkgs This is a big change that disentangles a lot of mistaken assumptions about mixing multiple versions of Nixpkgs, treating external flake inputs as gospel for the source of Nixpkgs and nix-darwin, etc.; the end result should be much simpler conceptually, but it will be a breaking change for anyone using `eval-config.nix` directly. Hopefully that shouldn't be a big issue, as it is more of an internal API and it's quite likely that existing uses may have been broken in the same way the internal ones were. It was previously easy to get into a state where your `lib` comes from nix-darwin's `nixpkgs` input or a global channel and your `pkgs` comes from another major version of Nixpkgs. This is pretty fundamentally broken due to the coupling of `pkgs` to its corresponding `lib`, but the brokenness was hidden much of the time until something surfaced it. Now there is exactly one mandatory `lib` input to system evaluation, and the handling of various additional options like `pkgs` and `system` can be done modularly; maintaining backwards compatibility with the previous calling convention is punted to the `default.nix` and `lib.darwinSystem` entry points. `inputs` is no longer read by nix-darwin or special in any way, merely a convention for user code, and the argument is retained in the entry points only for backwards compatibility. All correct invocations of the entry points should keep working after this change, and some previously-broken ones should be fixed too. The documentation and template have been adjusted to show the newly-recommended modular way of specifying various things, but no deprecation warnings have been introduced yet by this change. There is one potential, mostly cosmetic regression: `system.nixpkgsRevision` and related options are less likely to be set than before, in cases where it is not possible to determine the origin of the package set. Setting `nixpkgs.source` explicitly will make this work again, and I hope to look into sending changes upstream to Nixpkgs to make `lib.trivial.revisionWithDefault` behave properly under flakes, which would fix this regression and potentially allow reducing some of the complexity. Fixes: #669
2023-07-07 08:02:38 +00:00
modules = [
self.darwinModules.simple
{ nixpkgs.hostPlatform = system; }
];
};
in {
simple = simple.system;
inherit (simple.config.system.build.manual)
optionsJSON
manualHTML
manpages;
});
packages = forAllSystems (system: let
pkgs = import nixpkgs {
inherit system;
overlays = [ self.overlays.default ];
};
in {
default = self.packages.${system}.darwin-rebuild;
2023-07-01 15:11:16 +00:00
inherit (pkgs) darwin-option darwin-rebuild darwin-version darwin-uninstaller;
});
2020-10-18 10:46:59 +00:00
};
}