-
-
Notifications
You must be signed in to change notification settings - Fork 15.1k
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
Draft for overlays using flake.nix outputs.flakeModule
#222155
Conversation
(removed (dependencyOn flake-parts)) (addedOption `nixpkgs.output`)])
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.
Hi, and thank you for proposing a contribution!
This is quite a significant addition, so I've made thorough first review as you can see.
I think your commit messages are really interesting. Do you have tooling to process those sexprs?
We do have some guidelines for the format of commit messages. Would you be willing to adapt to those? They're listed here. They're probably not hugely specific rules for these commits, but I know that the other contributors will appreciate commit messages that fit in with the rest; certainly for the title part of the message.
I'd also like to ask you to squash your commits in the end, but keep a commit boundary between changes that could be used separately, such as for example the addition of types.overlay
.
flakeModule.nix
Outdated
merge = _loc: defs: | ||
let | ||
logWarning = | ||
if builtins.length defs > 1 |
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.
If you could implement support for mkOrder
, that'd be awesome, but otherwise, I'd be ok to just note this and consider this to be MVP.
if builtins.length defs > 1 | |
# TODO: do not warn when lib.mkOrder/mkBefore/mkAfter are used unambiguously | |
if builtins.length defs > 1 |
flakeModule.nix
Outdated
(builtins.seq | ||
logWarning |
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 could use lib.warnIf
to replace the seq
+ if
combination.
flakeModule.nix
Outdated
description = "Nixpkgs overlays"; | ||
default = [ ]; | ||
}; | ||
|
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 could add the Nixpkgs config
parameter if you like.
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.
Yes, that was already planned.
flakeModule.nix
Outdated
let | ||
inherit (lib) mkOption types; | ||
|
||
nixpkgsOverlaySubmodule = types.mkOptionType { |
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.
It would be great to have this in lib.types
instead of hidden away in a let
binding.
That way we can also reuse the existing test infrastructure in lib/tests/modules.sh
to test this type.
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.
nixpkgsOverlaySubmodule = types.mkOptionType { | |
nixpkgsOverlayType = types.mkOptionType { |
Just a type, not really a submodule. Confused me for a sec when I read it below.
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.
Yep, the nixos module will have to be merged with this, to avoid duplication. It is indeed a big change, structurally, but you already did most of the discovering with flake-parts. Good catch on the name. I copied a lot from flake-parts, so will be putting you in the authors of the final squash.
flakeModule.nix
Outdated
options = { | ||
overlays = mkOption { | ||
type = listOf nixpkgsOverlaySubmodule; | ||
description = "Nixpkgs overlays"; |
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.
A link to the Nixpkgs manual would be helpful.
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.
Hi, and thank you for proposing a contribution!
This is quite a significant addition, so I've made thorough first review as you can see.
I think your commit messages are really interesting. Do you have tooling to process those sexprs? We do have some guidelines for the format of commit messages. Would you be willing to adapt to those? They're listed here. They're probably not hugely specific rules for these commits, but I know that the other contributors will appreciate commit messages that fit in with the rest; certainly for the title part of the message.
I'd also like to ask you to squash your commits in the end, but keep a commit boundary between changes that could be used separately, such as for example the addition of
types.overlay
.
Yes, those are a proof of concept lang being developped dynamically. They will be processed eventually, when the first sajban implementation is out. For sure, I will learn about NixOS style commits and squash this PR when done. This is just a documenting PR. Thank you so much for flake-parts and for your review. I will be sending you some ouf our tokens when they come out in a few weeks. I'd be happy to have you on a live podcast to discuss Nix and its future. Cheers.
flakeModule.nix
Outdated
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.
Considering that the logic in this file is specific to the Nixpkgs part of the repo, could you move it into pkgs/top-level
?
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 mean the whole module? I was also wondering wether or not to bypass the impurity checks, since flakes are supposed (as far as I know) to be pure. Any thoughts?
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.
Indeed it shouldn't matter much. You can pass --impure
to override the pure behavior, but I don't think we should support any of the environment variables if that causes more complexity or effort. Users should pass any overrides and such in their expressions, and not through the environment, because most likely it affects more code than they wish for.
(added (flakeModule allPkgsPerSystem))]
The review done at this time were done in a live on youtube around 1:30:00 |
[(removed import) (added documentingComments)])
The draft is ready for eager testing. It is used currently in a fork of flake-parts. and you can see a naive test here: It will be used soon in clojix, which is an empty repo at time of writing. |
31fa2dd
to
2613e69
Compare
As an aside there is an argument to be made that NixOS' |
07ab644
to
b4e3577
Compare
I have gone ahead and bypassed |
You can see how flake-parts uses this here. |
👍
Optionality in module arguments themselves is a bit weird and unsupported, but if the value of module argument is a function, you should just get that function and no special behavior. In other words, if you have { hi, ... }:
{ config._module.args = f; } Then
If it relies on |
Not sure about
A clean slate. I see the appeal, but it might actually make the migration harder rather than easier. Realistically, we'll want to improve the individual options and take our time to do it, but I doubt that it's really worth renaming. Probably best to let the ecosystem complete a
This evaluation cost is negligible, especially in comparison with all the things that have to be evaluated just to get to a |
Thanks Robert, your comments are welcome and encouraging. I will polish this PR as soon as I start using it, which I am working on achieving with all my coding time. |
Any future work related to this will probably start from #231940 |
Description of changes
A draft for overlay using flake modules as developped by
flake-parts. A pull
request for flake-parts will complement this for testing soon.
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/
)