Throw an error for options without a type#162271
Conversation
Co-Authored-By: Janne Heß <janne@hess.ooo>
Makes all options rendered in the manual throw an error if they don't have a type specified. This is a follow-up to NixOS#76184 Co-Authored-By: Silvan Mosberger <contact@infinisil.com>
| : The type of the option (see [](#sec-option-types)). This | ||
| argument is mandatory for nixpkgs modules. Setting this is highly | ||
| recommended for the sake of documentation and type checking. In case it is | ||
| not set, a fallback type with unspecified behavior is used. |
There was a problem hiding this comment.
unspecified behavior
Wait what? Surely we can specify what the type is, or will be?
There was a problem hiding this comment.
I chose this wording because the current default type, types.unspecified, uses a merge function that's really not safe and fairly arbitrary:
- Booleans are merged using
or:true+false->true - Lists and strings are just concatenated together, which can be unsafe and makes the result depend on module order. Also relates to the deprecation of
types.string - Attribute sets are merged using
lib.mergeAttrs, which overrides properties depending on module order - Nested
mkIf's,mkMerge's and co. are not taken into account.
Not only does this align with the type name, but this behavior really wasn't ever specified to behave in this way, thus unspecified. This is also reflected in how types.unspecified is undocumented. I believe originally it was only meant to be used internally to signify an unspecified type.
In the future I believe we should make types.anything be the default type instead, which is a similarly generic type but without any of the above flaws. By saying the type is unspecified we leave the possibility open for changing it in the future without breaking people's expectations. If we do the switch to types.anything we can update this documentation to be more specific and strict.
There was a problem hiding this comment.
Ok, I can get on board with that.
Instead of anything I'd go with raw though, as it does not sneak extra arbitrary decisions into underspecified code. anything may be better than unspecified, but it is still arbitrary.
There was a problem hiding this comment.
Hmm yeah, maybe raw would be better, I can see a case to be made for either, though that's a discussion for the future.
roberth
left a comment
There was a problem hiding this comment.
lgtm, but can't vouch for the changed types in the NixOS modules
|
This pull request has been mentioned on NixOS Discourse. There might be relevant details there: https://discourse.nixos.org/t/tweag-nix-dev-update-25/18003/1 |
For now at least. I expect someone will find a working type later. It's incorrect and was causing bad issues. Example test case: nix-instantiate nixos/release.nix -A tests.xfce.x86_64-linux --dry-run This is a partial revert of commit b2d803c from PR NixOS#162271.
Motivation for this change
This is a revised version of #127066, which is a follow-up to #76184. This PR improves the types, error message, documentation and updates it to work with #149532.
Warnings are thrown when building the manual. Only options included in the manual are required to have a type specified. E.g. with this
configuration.nix:building it gives you
Closes #76184
Closes #141730
Closes #141760
Ping @dasJ @domenkozar @roberth @primeos
Things done
sandbox = trueset 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.shto update generated release notes