nixos/system-path: convert environment.systemPackages to an attrset#255086
nixos/system-path: convert environment.systemPackages to an attrset#255086r-vdp wants to merge 6 commits intoNixOS:masterfrom
Conversation
74a0c32 to
02edf48
Compare
02edf48 to
f0ce34f
Compare
|
You should mark this as a draft if you're still working on it. |
|
Right, I removed the WIP label and converted to draft for now. I'd want to do a bit more tidying up before merging, but before spending more time on this I'd first like to know that people agree with the approach. |
|
I think the approach is really good. I've been discussing with some people that the systemPackages should be an overridable attrset but never acted on it, so I'm happy that someone else picked it up. The attrset way of declaring a package is a little verbose, but I'd assume that most people are just using the list way, so its fine. |
a2d8e5d to
176d3ca
Compare
|
@nikstur after implementing the suggestions from @infinisil, the way to declare a package using the attrset approach became a lot more convenient, as you can see in the test case. We can deduce the outputs automatically now. |
4ab1693 to
c1d6dfe
Compare
|
I think the following definition leads to an unfortunate error message: systemPackages = pkgs.hello;
|
|
This also needs a release note and an update to the option description to clarify what the attribute name is for. |
e8d72ef to
6c86b56
Compare
There was a problem hiding this comment.
This PR currently adds 4 non-trivial, untested and undocumented lib functions. Either those should be done in smaller PRs (see also the new lib PR guidelines), or we shouldn't expose them publicly, as hinted by Robert.
6c86b56 to
e119b86
Compare
There was a problem hiding this comment.
I checked several of the rebuilds and they are due to the ordering of the paths in the resulting list. This was in definition order before, and is in alphabetical order now, due to attrsets being sorted.
I believe this is important enough to be added to the release note.
While the definition order is sufficiently "unpredictable" that it should not be relied upon, that doesn't exclude the possibility that some configurations happen to rely on it by accident.
Could you add an item to describe this breaking aspect, in the Backward Incompatibilities section below?
There was a problem hiding this comment.
| This change is backwards compatible, but we might deprecate the list syntax in a future release. | |
| This change is backwards compatible, unless the configuration relies on a specific ordering of packages. We might deprecate the list syntax in a future release. |
Suppose I want util-linux for obvious reasons, but I also want my own custom mount executable from a custom package. How do I achieve that? After reading this, it
d looks like I'm stuck, or I'd have to meddle with the util-linux definition. I think this also needs to reference the priority option.
Please describe an alternative to list ordering here and in the option doc.
nixos/modules/config/system-path.nix
Outdated
There was a problem hiding this comment.
Could you describe the effect of priority?
E.g. what does a large value do? Do packages without a priority have a default priority?
I think you could link to https://nixos.org/manual/nixpkgs/stable/#var-meta-priority, but that doc isn't much better.
Maybe this? https://nixos.org/manual/nix/stable/command-ref/nix-env/install.html?highlight=priority#description
I think it'd be ok to copy some of this information, because
- NixOS/nixpkgs duplicates this logic anyway
- It's not going to change in Nix, because that'd break profiles for no good reason
|
I am sorry if that was already answered in some thread, I didn't read all of them but what happens to packages that where before duplicated by name in the list but not by the files they contain? |
What do you mean exactly by "the files they contain"? Packages added through the list syntax, end up in the attrset with their drv path as key, so unless they come from the same derivation, they would end up under different keys. If they do come from the same derivation, then their outputs will be combined in the list of outputs to install. Does that answer your question? |
|
Yeah, I first thought they would be using the package variable as a key which isn't unique but the drv path must be unique. 👍🏼 |
b350003 to
209683e
Compare
This allows easily disabling or overriding a package.
… that have different priorities
209683e to
4c10a51
Compare
|
There's currently still an issue with |
|
This pull request has been mentioned on NixOS Discourse. There might be relevant details there: |
Any update on this? :3 |
|
This pull request has been mentioned on NixOS Discourse. There might be relevant details there: |
|
Any progress? |
|
This pull request has been mentioned on NixOS Discourse. There might be relevant details there: |
|
This pull request has been mentioned on NixOS Discourse. There might be relevant details there: |
Description of changes
Lists are pretty bad for overriding, this PR proposes to use an attribute set for
environment.systemPackagesso that we can more easily disable packages or override the derivation for a package.In order not to break the current API, we use the
coercedTotype so that we can still accept a list of derivations and we convert this list into an attribute set. This should therefore be a non-breaking change.We also allow for a shorthand syntax:
Which gets coerced into
where the outputs were taken from
meta.outputsToInstalland can be individually disabled (hence the attrset that maps every output to a boolean).The nixos test gives a good overview of what the syntax would look like.
@roberth @infinisil @nikstur : I'd love to get your thoughts on this.