-
-
Notifications
You must be signed in to change notification settings - Fork 14.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
Configuration file formats for JSON, INI, YAML and TOML #75584
Conversation
Potentially/Eventually these formats might be implemented using |
@infinisil awesome stuff! |
(This still needs a bit of docs probably and a history cleanup at least btw, before anybody merges) |
e5661da
to
3974642
Compare
I've now rebased this ontop of #70138 to implement types where values can depend on other values. E.g. this previously threw an infinite recursion error, but now it doesn't anymore: { lib, config, ... }:
let format = lib.formats.json;
in {
options.settings = lib.mkOption {
type = format.type;
default = {};
};
config = {
settings.foo = true;
settings.bar = lib.mkIf config.settings.foo "Foo is true!";
environment.etc.test.text = format.generate config.settings;
};
} Due to how the implementation works, it's however a bit more cumbersome if you aren't sure whether an attribute exists at all. This is how that can now be handled gracefully: {
# To make sure the `.name` attribute exists
settings.name = format.empty;
# To handle the case of `.name` being empty
settings.greeting = "Hello, ${format.get "nobody" config.settings.name}!";
} This will generate Alternatively if you don't mind {
settings.name = lib.mkDefault "nobody";
settings.greeting = "Hello, ${config.settings.name}!";
} Which will generate |
3974642
to
3501efa
Compare
With JSONValue from: * NixOS/nixpkgs#75584
With JSONValue from: * NixOS/nixpkgs#75584
With JSONValue from: * NixOS/nixpkgs#75584
With JSONValue from: * NixOS/nixpkgs#75584
lib/settings-formats.nix
Outdated
|
||
empty = { _nixos_empty_json_value = | ||
throw ("You tried to access an option value of type json that is empty. " | ||
+ "Use `lib.formats.json.get` on the value before using it."); |
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 might be a good idea to only have a single empty value for all
On IRC @adisbladis brought to my attention that to support more formats like TOML, we could use |
I'd review it if it was written with terminal length in mind, but currently it's not feasible via github ui. |
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 should be noted in the docs that some of these functions may write to the store, which is not safe when Nix is handling secrets. This is in contrast to builtins.toJSON
etc, which operate entirely in memory.
pkgs/pkgs-lib/default.nix
Outdated
# they depend on some packages. This notably is *not* for supporting package | ||
# building, instead pkgs/build-support is the place for that. | ||
{ lib, pkgs }: { | ||
# setting format types and generators. These would fit in lib/types.nix, but |
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.
# setting format types and generators. These would fit in lib/types.nix, but | |
# setting format types and generators. These do not fit in lib/types.nix, because |
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.
pkgs/pkgs-lib/default.nix
Outdated
@@ -0,0 +1,11 @@ | |||
# pkgs-lib is for things that should be in lib, but can't beceause |
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.
# pkgs-lib is for things that should be in lib, but can't beceause | |
# pkgs-lib is for functions that can't be in lib, because |
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.
pkgs/top-level/stage.nix
Outdated
@@ -75,6 +75,11 @@ let | |||
inherit (self) runtimeShell; | |||
}; | |||
|
|||
pkgsLib = self: super: import ../pkgs-lib { |
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.
An overlay is unnecessary because the same could be achieved by putting formats
in all-packages.nix
.
Categorizing functions separately from packages is beyond the scope of this change. It can be discussed in a separate issue/pr, although I doubt its usefulness.
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.
Doesn't have to be just functions though, can be arbitrary values, and other functions like fetchgit
wouldn't fit in a pkgs-lib. I guess it won't be a problem to just put formats
in all-packages.nix
, but imo having a separation between "things needed to create packages" and "things that just happen to depend on pkgs" would make sense. Could still introduce that in the future though
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.
Not using an overlay anymore now
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.
All of formats
, fetchgit
, dockerTools
depend on Nixpkgs, take arguments, produce derivations, are maintained and released in the same way. What makes formats
so architecturally different that it needs to be treated differently?
imo having a separation between "things needed to create packages" and "things that just happen to depend on pkgs" would make sense. Could still introduce that in the future though
If only one attribute is separate it doesn't make sense though. For it to make sense it must be applied to the whole of Nixpkgs and it must have practical benefits. The prior can be done in the future and I'm skeptical about the benefits, but would love to be proven wrong in that same future.
For now please follow the example of, say, dockerTools
.
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 like my view of the PR was outdated (maybe caused by the current service disruption?) anyway, thanks for removing the overlay. Currently build-support
has the role of pkgs-lib
so you may want to move the files to build-support/formats
. I don't really like that name either so I'm going to leave this change up to you to decide.
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.
The difference between e.g. fetchgit
and formats.json
is that fetchgit
is needed for building many of the pkgs.*
derivations, whereas formats.json
doesn't have any use for any pkgs.*
. Instead formats
are mostly just useful for NixOS modules (really, the module system in general, so it wouldn't fit in nixos/lib
)
This is also why I don't think build-support
would make sense, because formats.json
doesn't support any package building.
this is useful https://github.com/StylishThemes/GitHub-code-wrap |
For NixOS modules at least it doesn't make much of a difference, because the only way for a string (which |
76e8e4a
to
83b1688
Compare
@roberth Looking good now? |
I wonder if |
Awesome, thanks for merging! @Ericson2314 I intentionally didn't name it |
Foremost, the message was discarding double quotes on one side of the diff, which was super-confusing to me, as I thought that the format convertor broke that when in fact only whitespace was changed. I thought I'd cat the files, but then... switching to `diff -u` seemed self-sufficient. It felt sufficiently non-controversial to push directly, but certainly feel free to improve further.
@infinisil you might want to update this documentation section as well https://nixos.org/manual/nixpkgs/unstable/#sec-generators |
Actually reading |
Motivation for this change
This is a main part of the implementation of NixOS/rfcs#42 (see https://github.com/Infinisil/rfcs/blob/config-option/rfcs/0042-config-option.md#part-1-1).
Since that part of the RFC is fairly uncontroversial, I think we can merge this before the RFC is eventually accepted. This allows people to use such types in their NixOS options already.
Ping @Profpatsch @rycee @aanderse @kampka
Things done
Here's a simple example module though: