| Age | Commit message (Collapse) | Author |
|---|
|
Only overridden settings are sent to the daemon, and we're going to do the same
for the build hook to. It needs to be ensured that overridden settings are in
fact consistently marked as such, so that they actually get sent.
Change-Id: I7cd58d925702f86cf2c35ad121eb191ceb62a355
|
|
Change-Id: I5566a9858ba255f4ac5051d1368c7dfb24460f0a
|
|
This makes no changes to logic but makes the `ApplyConfigOptions` value
available to consumers.
Change-Id: I88cf53d38faac8472c556aee55c13d0acbd1e5db
|
|
There have been multiple setting types for paths that are supposed to be
canonicalised, depending on whether zero or one, one, or any number of paths is
to be specified. Naturally, they behaved in slightly different ways in the
code. Simplify things by unifying them and removing special behaviour (mainly
the "multiple paths type can coerce to boolean" thing).
Change-Id: I7c1ce95e9c8e1829a866fb37d679e167811e9705
|
|
Instead of doing a linear search on an std::set, we use a bitset enum.
Change-Id: Ide537f6cffdd16d06e59aaeb2e4ac0acb6493421
|
|
They are like experimental features, but opt-in instead of opt-out. They
will allow us to gracefully remove language features. See #437
Change-Id: I9ca04cc48e6926750c4d622c2b229b25cc142c42
|
|
Change-Id: Ic1f68e6af658e94ef7922841dd3ad4c69551ef56
|
|
Change-Id: I4f642d1046d56b5db26f1b0296ee16a0e02d444a
|
|
Change-Id: Ifa89a529e7e34e7291eca87d802d2f569cf2493e
|
|
Change-Id: I1165f6ef033a5f757ca3716d3f8008ba36b01fd0
|
|
These now have equivalents in the standard lib in C++20. This change was
performed with a custom clang-tidy check which I will submit later.
Executed like so:
ninja -C build && run-clang-tidy -checks='-*,nix-*' -load=build/libnix-clang-tidy.so -p .. -fix ../tests | tee -a clang-tidy-result
Change-Id: I62679e315ff9e7ce72a40b91b79c3e9fc01b27e9
|
|
config: add included files into parsedContents before applying
(cherry picked from commit 82359eba6b692691ef08a71196ef25a61bc4d3d3)
Change-Id: Idde3177010fec7b8bafe6088c3c23d5caf491845
|
|
Improvements in src/libutil/config.*
(cherry picked from commit dea63bb81078d7290410544285c6df1a8e002952)
Change-Id: I8090eb2ad393dd9964cf2d5254ec8c796b1bd367
|
|
libutil: Small improvements
(cherry picked from commit edc07588ecd5053da57c2ab6c2543abf49730ce3)
Change-Id: I01a481d872d859b372a4bade9bebd3dab2fb4efb
|
|
Fix broken move
(cherry picked from commit aa4f41d796630004e90790bffe2239420f77f696)
Change-Id: I39d3f9f4f27328500de005c9205d905c55d6f9ea
|
|
Rather than doing `allowEmpty` as boolean, have separate types and use
`std::optional`. This makes it harder to forget the possibility of an
empty path.
The `build-hook` setting was categorized as a `PathSetting`, but
actually it was split into arguments. No good! Now, it is
`Setting<Strings>` which actually reflects what it means and how it is
used.
Because of the subtyping, we now also have support for
`Setting<std::optional<String>>` in general. I imagine this can be used
to clean up many more settings also.
|
|
Issues:
1. Features gated on disabled experimental settings should warn and be
ignored, not silently succeed.
2. Experimental settings in the same config "batch" (file or env var)
as the enabling of the experimental feature should work.
3. For (2), the order should not matter.
These are analogous to the issues @roberth caught with my changes for
arg handling, but they are instead for config handling.
Co-authored-by: Robert Hensing <roberth@users.noreply.github.com>
|
|
Fix #8162
The test is changed to compare `nlohmann::json` values, not strings of dumped
JSON, which allows us to format things more nicely.
|
|
This is somewhat hacky fix just for 2.15. I unintentionally hid them
from the manual, when no one wanted to hide them that (including
myself). I also required the experimental feature to be enabled in an
order-dependent way, which is not good.
The simplest fix for this immanent release is just to always show them,
and always allow them to be set.
Effectively undoes some changes from aa663b7e89d3d02248d37ee9f68b52770b247018
|
|
If we conditionally "declare" the argument, as we did before, based upon
weather the feature is enabled, commands like
nix --experimental-features=foo ... --thing-gated-on-foo
won't work, because the experimental feature isn't enabled until *after*
we start parsing.
Instead, allow arguments to also be associated with experimental
features (just as we did for builtins and settings), and then the
command line parser will filter out the experimental ones.
Since the effects of arguments (handler functions) are performed right
away, we get the required behavior: earlier arguments can enable later
arguments enabled!
There is just one catch: we want to keep non-positional
flags...non-positional. So if
nix --experimental-features=foo ... --thing-gated-on-foo
works, then
nix --thing-gated-on-foo --experimental-features=foo ...
should also work.
This is not my favorite long-term solution, but for now this is
implemented by delaying the requirement of needed experimental features
until *after* all the arguments have been parsed.
|
|
We hide them in various ways if the experimental feature isn't enabled.
To do this, we had to move the experimental features list out of
libnixstore, because the setting machinary itself depends on it. To do
that, we made a new `ExperimentalFeatureSettings`.
|
|
This is needed in subsequent commits to allow the settings and CLI args
infrastructure itself to read this setting.
|
|
|
|
Also use std::string_view in a few more places.
|
|
|
|
|
|
Rather than having them plain strings scattered through the whole
codebase, create an enum containing all the known experimental features.
This means that
- Nix can now `warn` when an unkwown experimental feature is passed
(making it much nicer to spot typos and spot deprecated features)
- It’s now easy to remove a feature altogether (once the feature isn’t
experimental anymore or is dropped) by just removing the field for the
enum and letting the compiler point us to all the now invalid usages
of it.
|
|
|
|
Fill `NIX_CONFIG` with the value of the current Nix configuration before
calling the post-build-hook.
That way the whole configuration (including the possible
`experimental-features`, a possibly `--store` option or whatever) will
be made available to the hook
|
|
Fixes #4671.
|
|
|
|
Fixes: warning: unknown setting 'extra-sandbox-paths'
|
|
|
|
This removes the extra-substituters and extra-sandbox-paths settings
and instead makes every array setting extensible by setting
"extra-<name> = <value>" in the configuration file or passing
"--<name> <value>" on the command line.
|
|
|
|
|
|
Allows Configuration values that are space-separated key=value pairs.
|
|
|
|
Instead make a separate header with the template implementation of
`BaseSetting<T>::toJSONObj` that can be included where needed
|
|
Don't let it just contain the value, but also the other fields of the
setting (description, aliases, etc..)
|
|
|
|
|
|
|
|
This means we don't have two (divergent) sets of option descriptions
anymore.
|
|
This moves the actual parsing of configuration contents into applyConfig
which applyConfigFile is then going to call. By changing this we can now
test the configuration file parsing without actually create a file on
disk.
|
|
|
|
This allows overriding the priority of substituters, e.g.
$ nix-store --store ~/my-nix/ -r /nix/store/df3m4da96d84ljzxx4mygfshm1p0r2n3-geeqie-1.4 \
--substituters 'http://cache.nixos.org?priority=100 daemon?priority=10'
Fixes #3264.
|
|
Allow global config settings to be defined in multiple Config
classes. For example, this means that libutil can have settings and
evaluator settings can be moved out of libstore. The Config classes
are registered in a new GlobalConfig class to which config files
etc. are applied.
Relevant to https://github.com/NixOS/nix/issues/2009 in that it
removes the need for ad hoc handling of useCaseHack, which was the
underlying cause of that issue.
|
|
|
|
|
