2025-01-08 19:10:22 +00:00
|
|
|
|
let
|
|
|
|
|
nixDarwinVersion = builtins.fromJSON (builtins.readFile ./version.json);
|
|
|
|
|
|
|
|
|
|
checkRelease = lib:
|
|
|
|
|
# Avoid breaking configurations when the unstable Nixpkgs version
|
|
|
|
|
# rolls over.
|
|
|
|
|
#
|
|
|
|
|
# TODO: Something more refined than this would be ideal, as this
|
|
|
|
|
# still means you could be using unstable nix-darwin 25.05 with
|
|
|
|
|
# Nixpkgs 26.05, which would be unfortunate.
|
|
|
|
|
if nixDarwinVersion.isReleaseBranch then
|
|
|
|
|
lib.trivial.release == nixDarwinVersion.release
|
|
|
|
|
else
|
|
|
|
|
lib.versionAtLeast lib.trivial.release nixDarwinVersion.release;
|
|
|
|
|
in
|
|
|
|
|
|
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 09:02:38 +01:00
|
|
|
|
{ lib
|
2021-04-05 14:05:02 +01:00
|
|
|
|
, modules
|
2020-10-18 12:46:59 +02:00
|
|
|
|
, baseModules ? import ./modules/module-list.nix
|
2021-04-05 14:05:02 +01:00
|
|
|
|
, specialArgs ? { }
|
2021-12-08 15:13:24 -08:00
|
|
|
|
, check ? true
|
2025-01-08 19:10:22 +00:00
|
|
|
|
, enableNixpkgsReleaseCheck ? true
|
2020-10-18 12:46:59 +02:00
|
|
|
|
}@args:
|
|
|
|
|
|
2025-01-08 19:10:22 +00:00
|
|
|
|
assert enableNixpkgsReleaseCheck -> checkRelease lib || throw ''
|
|
|
|
|
|
|
|
|
|
nix-darwin now uses release branches that correspond to Nixpkgs releases.
|
|
|
|
|
The nix-darwin and Nixpkgs branches in use must match, but you are currently
|
|
|
|
|
using nix-darwin ${nixDarwinVersion.release} with Nixpkgs ${lib.trivial.release}.
|
|
|
|
|
|
|
|
|
|
On macOS, you should use either the `nixpkgs-unstable` or
|
|
|
|
|
`nixpkgs-YY.MM-darwin` branches of Nixpkgs. These correspond to the
|
|
|
|
|
`master` and `nix-darwin-YY.MM` branches of nix-darwin, respectively. Check
|
|
|
|
|
<https://status.nixos.org/> for the currently supported Nixpkgs releases.
|
|
|
|
|
|
|
|
|
|
If you’re using flakes, make sure your inputs look like this:
|
|
|
|
|
|
|
|
|
|
inputs = {
|
|
|
|
|
nixpkgs.url = "github:NixOS/nixpkgs/NIXPKGS-BRANCH";
|
|
|
|
|
nix-darwin.url = "github:LnL7/nix-darwin/NIX-DARWIN-BRANCH";
|
|
|
|
|
nix-darwin.inputs.nixpkgs.follows = "nixpkgs";
|
|
|
|
|
# …
|
|
|
|
|
};
|
|
|
|
|
|
|
|
|
|
If you’re using channels, you can check your current channels with:
|
|
|
|
|
|
|
|
|
|
$ sudo nix-channel --list
|
|
|
|
|
nixpkgs https://nixos.org/channels/NIXPKGS-BRANCH
|
|
|
|
|
darwin https://github.com/LnL7/nix-darwin/archive/NIX-DARWIN-BRANCH.tar.gz
|
|
|
|
|
…
|
|
|
|
|
$ nix-channel --list
|
|
|
|
|
…
|
|
|
|
|
|
|
|
|
|
If `darwin` or `nixpkgs` are present in `nix-channel --list` (without
|
|
|
|
|
`sudo`), you should delete them with `nix-channel --remove NAME`. These can
|
|
|
|
|
contribute to version mismatch problems.
|
|
|
|
|
|
|
|
|
|
You can then fix your channels like this:
|
|
|
|
|
|
|
|
|
|
$ sudo nix-channel --add https://nixos.org/channels/NIXPKGS-BRANCH nixpkgs
|
|
|
|
|
$ sudo nix-channel --add https://github.com/LnL7/nix-darwin/archive/NIX-DARWIN-BRANCH.tar.gz darwin
|
|
|
|
|
$ sudo nix-channel --update
|
|
|
|
|
|
|
|
|
|
After that, activating your system again should work correctly. If it
|
|
|
|
|
doesn’t, please open an issue at
|
|
|
|
|
<https://github.com/LnL7/nix-darwin/issues/new> and include as much
|
|
|
|
|
information as possible.
|
|
|
|
|
'';
|
|
|
|
|
|
2020-10-18 12:46:59 +02:00
|
|
|
|
let
|
2021-12-20 20:29:59 +01:00
|
|
|
|
argsModule = {
|
2020-10-18 12:46:59 +02:00
|
|
|
|
_file = ./eval-config.nix;
|
|
|
|
|
config = {
|
2021-12-20 20:29:59 +01:00
|
|
|
|
_module.args = {
|
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 09:02:38 +01:00
|
|
|
|
inherit baseModules modules;
|
2021-12-20 20:29:59 +01:00
|
|
|
|
};
|
2020-10-18 12:46:59 +02:00
|
|
|
|
};
|
|
|
|
|
};
|
|
|
|
|
|
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 09:02:38 +01:00
|
|
|
|
eval = lib.evalModules (builtins.removeAttrs args [ "lib" ] // {
|
2024-06-13 13:52:29 +01:00
|
|
|
|
class = "darwin";
|
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 09:02:38 +01:00
|
|
|
|
modules = modules ++ [ argsModule ] ++ baseModules;
|
2020-10-18 12:46:59 +02:00
|
|
|
|
specialArgs = { modulesPath = builtins.toString ./modules; } // specialArgs;
|
|
|
|
|
});
|
|
|
|
|
in
|
|
|
|
|
|
|
|
|
|
{
|
2023-06-22 13:08:42 +01:00
|
|
|
|
inherit (eval._module.args) pkgs;
|
2020-10-18 12:46:59 +02:00
|
|
|
|
inherit (eval) options config;
|
2023-02-27 12:41:00 +01:00
|
|
|
|
inherit (eval) _module;
|
2020-10-18 12:46:59 +02:00
|
|
|
|
|
|
|
|
|
system = eval.config.system.build.toplevel;
|
|
|
|
|
}
|