-
-
Notifications
You must be signed in to change notification settings - Fork 14.9k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
nixos/top-level: add includeBuildDependencies option #195511
Conversation
ea1c372
to
0180978
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I like the idea.
It's a problem I've also encountered and solved independently for nixos/tests/nixops/default.nix
, but that solution required virtualisation.additionalPaths
; so not immediately transferable to NixOS itself. I'm glad to see a more general and cleaner solution.
If I'm not mistaken, the nixops test could be supported the following instead of my hacky solution:
deployer.system.extraDependencies = nodes.server.config.system.build.toplevel;
server.system.includeBuildDependencies = true;
You might also be interested in what I've written down for a more efficient solution in #180529, but let's not work on that in this PR.
0180978
to
abac59a
Compare
abac59a
to
3ac0784
Compare
3ac0784
to
cd10904
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks good to me.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Just some doc improvements, because I think we should be more explicit about what happens.
Whether to include the build closure of the whole system in | ||
its runtime closure. This can be useful for making changes | ||
fully offline, as it results in all sources and patches | ||
required to build the system being included. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Whether to include the build closure of the whole system in | |
its runtime closure. This can be useful for making changes | |
fully offline, as it results in all sources and patches | |
required to build the system being included. | |
Whether to include the build closure of the whole system in | |
its runtime closure. This can be useful for making changes | |
fully offline, as it includes all sources, patches and intermediate | |
outputs that are required to build all the derivations. | |
All derivations really means all derivations, from the bootstrapping | |
tools, to the build tools, to the packages, and all the way up to the | |
configuration files of the system. |
fully offline, as it results in all sources and patches | ||
required to build the system being included. | ||
|
||
Note that this increases closure size drastically: a minimal |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Note that this increases closure size drastically: a minimal | |
This increases the system's size drastically: a minimal |
... or do some people scan for "Note" in text? I don't think I do.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
(I do, but I am fine either way)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Note that this increases closure size drastically: a minimal | |
Note that this increases the system size drastically: a minimal |
This works when enabled on the deployer instead, which makes more sense anyway. |
You may include my nixops test patch, although I'd prefer a simple stand-alone test that doesn't involve a specific deployment tool, but just NixOS. 0001-nixosTests.nixops.unstable.legacyNetwork-Use-system..patch.txt Refs |
cd10904
to
44b293b
Compare
the compilers. This increases the size and build/download time | ||
of the system drastically: a minimal configuration with no | ||
extra services enabled grows from ~670MiB in size to 13.5GiB, | ||
and takes proportionally longer to build. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't think the build is much slower, is it? Isn't this more about substituting many more dependencies?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
You're absolutely right. Building the system entirely from scratch without substitution should take pretty much the same amount of time as before.
This option allows adding the build closure of the system to its runtime closure, enabling fully-offline rebuilds (as long as no new packages are added).
44b293b
to
eb45cd5
Compare
Thanks @lheckemann for polishing the implementation. I'll add this to the nixops test so that it's tested at least somewhere. |
This pull request has been mentioned on NixOS Discourse. There might be relevant details there: https://discourse.nixos.org/t/declarative-vms-ubuntu-on-top-of-nixos/34592/2 |
Description of changes
This option allows adding the build closure of the system to its runtime closure, enabling fully-offline rebuilds (as long as no new packages are added).
Things done
sandbox = true
set innix.conf
? (See Nix manual)nix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD"
. Note: all changes have to be committed, also see nixpkgs-review usage./result/bin/
)nixos/doc/manual/md-to-db.sh
to update generated release notes