| Commit message (Collapse) | Author | Age |
... | |
|
|
|
|
|
|
| |
Submodules that have a freeform type set behave as if that was the type
of the option itself (for values that don't have an option). Since the
submodules options are shown as separate entries in the manual, it makes
sense to show the freeform type as the submodule type.
|
|
|
|
|
| |
The error message is already helpfully verbose, so there's little
reason to shorten the informational URL.
|
|
|
|
|
| |
This more intuitively matches `types.either` and allows paths to be
coerced to submodules again, which was inhibited by #76861
|
|
|
|
|
| |
This option namespace is not a part of NixOS
so we shouldn't provide this warning for it.
|
|\
| |
| | |
tree-wide: fix more warning related to loaOf deprecation
|
| |
| |
| |
| | |
Now we suggest correct names for all options in Nixpkgs and also home-manager at the time of writing.
|
| | |
|
| |
| |
| |
| |
| | |
Not all modules use name attribute as the name of the submodule, for example,
environment.etc uses target. We will need to maintain a list of exceptions.
|
|\ \
| |/
|/| |
lib/types: Allow paths as submodule values
|
| | |
|
| |
| |
| |
| |
| |
| |
| | |
The standard attrsOf is strict in its *values*, meaning it's impossible to
access only one attribute value without evaluating all others as well.
lazyAttrsOf is a version that doesn't have that problem, at the expense
of conditional definitions not properly working anymore.
|
|/
|
|
| |
Co-Authored-By: Robert Hensing <roberth@users.noreply.github.com>
|
|\
| |
| | |
lib/types: Fix path type check
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Previously when this function was called without a value coercible to a
string it would throw an error instead of returning false. Now it does.
As a result this now allows the use of a type like `either path attrs`
without it erroring out when a definition is an attribute set.
The warning about there not being a isPath primop was removed because
this is not the case anymore, there is builtins.isPath. But also there
always was `builtins.typeOf x == "path"` that could've been used
instead. However the path type now stands for more than just path types,
but absolute paths in general.
|
|/ |
|
|
|
|
|
|
|
|
|
| |
This reverts commit eec83d41e3e7d9ad5bc1086198d972d55bab1203.
This broke hydra evaluation because with this commit submodule values
are allowed to be paths, however the certmgr module uses `either
(submodule ...) path` in its type, meaning it already used paths for
something else which would now be interpreted as a submodule.
|
| |
|
| |
|
|\ |
|
| | |
|
| | |
|
|/ |
|
|\
| |
| | |
lib/types: Add oneOf, extension of either to a list of types
|
| | |
|
|/
|
|
| |
Change to `mergeEqualOption`.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The explicit remove helped to uncover some hidden uses of `optionSet`
in NixOps. However it makes life harder for end-users of NixOps - it will
be impossible to deploy 19.03 systems with old NixOps, but there is no
new release of NixOps with `optionSet` fixes.
Also, "deprecation" process isn't well defined. Even that `optionSet` was
declared "deprecated" for many years, it was never announced. Hence, I
leave "deprecation" announce. Then, 3 releases after announce,
we can announce removal of this feature.
This type has to be removed, not `throw`-ed in runtime, because it makes
some perfectly fine code to fail. For example:
```
$ nix-instantiate --eval -E '(import <nixpkgs/lib>).types' --strict
trace: `types.list` is deprecated; use `types.listOf` instead
error: types.optionSet is deprecated; use types.submodule instead
(use '--show-trace' to show detailed location information)
```
|
| |
|
|
|
|
| |
mapAttrs)
|
| |
|
|
|
|
|
|
|
|
|
| |
The previous description "string" is misleading in the full options
manual pages; they are actually concatenated strings, with a specific
character.
The empty string version ("types.string") has been special-cased to
provide a better message.
|
|
|
|
|
| |
Since the `assertOneOf` uses `lib.generators`, they are not really trivial
anymore and should go into their own library file.
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
| |
Fixes #40463
This is related to change 1d56d0c8a79334cd7149fd580512046558eaac78
|
|
|
|
|
|
|
| |
Assigning a list of 10 or more elements to an option having the type
`loaOf a` produces a configuration value that is not honoring the
order of the original list. This commit fixes this and a related issue
arising when 10 or more lists are merged into this type of option.
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
Without this change
(coercedTo str toInt int).check "foo"
would evaluate to true, even though
(coercedTo str toInt int).merge {} [{ value = "foo"; }]
will throw an error because "foo" can't be coerced to an int.
|
| |
|
| |
|
|
|
|
|
|
|
|
|
| |
This file doesn't evaluate in 32-bit versions of Nix because the integer
type is a signed 32-bit integer there, so 4294967296 causes an 'invalid
integer' error. I see no other way around than commenting this out :(
(s32 could be made to work by tweaking the expressions a bit, but didn't
do that for now since it'd be asymmetric to have s32 but no u32).
|
| |
|
|
|
|
| |
For values that are positive, but cannot be 0.
|
| |
|
|
|
|
|
|
| |
Mirrors the way it’s done in modern low-level languages like Rust (by input of
@nbp).
Removes the signed alias for int.
|
|
|
|
| |
Will be introduced as a taggedUnion, once that type is in nixpkgs.
|
| |
|
|
|
|
|
| |
It is sometimes necessary to restrict the domain of integers for configurations,
as well as restricting them to unsigned/positive values.
|