| Commit message (Collapse) | Author | Age |
|---|
| |
|
|
|
| |
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.
|
| |
|
|
| |
An int type that checks the value range.
|