functional2: improve `NixSettings` #846

New issue

Open

opened 2025-06-08 18:36:16 +00:00 by commentatorforall · 4 comments

commentatorforall commented

2025-06-08 18:36:16 +00:00

Member

Currently, the NixSettings class creates a string config which the environment variable is set to.
This creates problems with current tests from the functional test-suit, which require default values and/or the existence of the nix.conf file.

Additionally the amount of options to set for the config is very limited, e.g. not allowing extra-deprecated-features turning the sandbox on or off etc.

Describe the solution you'd like

The implementation of NixSettings should be overhauled to write to the nix.conf file instead of an environment variable and to support more settings.

Describe alternatives you've considered

A clear and concise description of any alternative solutions or features you've considered.

Additional context

see

 cat > "$NIX_CONF_DIR"/nix.conf <<EOF
 build-users-group =
 keep-derivations = false
 sandbox = false
 experimental-features = nix-command
 gc-reserved-space = 0
 substituters =
 flake-registry = $TEST_ROOT/registry.json
 show-trace = true
 include nix.conf.extra
 trusted-users = $(whoami || id -u)
 EOF
 cat > "$NIX_CONF_DIR"/nix.conf.extra <<EOF
 fsync-metadata = false
 extra-experimental-features = flakes
 !include nix.conf.extra.not-there
 EOF

for the defaults provided by functional (not all of them are sensible)

## Is your feature request related to a problem? Please describe. Currently, the `NixSettings` class creates a string config which the environment variable is set to. This creates problems with current tests from the `functional` test-suit, which require default values and/or the existence of the `nix.conf` file. Additionally the amount of options to set for the config is very limited, e.g. not allowing `extra-deprecated-features` turning the `sandbox` on or off etc. ## Describe the solution you'd like The implementation of `NixSettings` should be overhauled to write to the `nix.conf` file instead of an environment variable and to support more settings. ## Describe alternatives you've considered A clear and concise description of any alternative solutions or features you've considered. ## Additional context see https://git.lix.systems/lix-project/lix/src/commit/b70bbbe680ff5f5ab6e35a21a091d0f845278cda/tests/functional/init.sh#L21-L38 for the defaults provided by `functional` (not all of them are sensible)

commentatorforall added the

testing

devx

labels

2025-06-08 18:36:16 +00:00

commentatorforall added this to the functional2 project

2025-06-08 18:36:16 +00:00

commentatorforall commented

2025-06-25 08:10:09 +00:00

Author

Member

having played around, trying to get the why-depends test to working, i'd like to see the following defaults:

show-trace = true
sandbox = true
sandbox-paths = [] # or /nix/store; have to play around a bit more with that to see if this is avoidable
experimental-features = [] # to allow for += assignments
substituters = []

having played around, trying to get the `why-depends` test to working, i'd like to see the following defaults: ``` show-trace = true sandbox = true sandbox-paths = [] # or /nix/store; have to play around a bit more with that to see if this is avoidable experimental-features = [] # to allow for += assignments substituters = [] ```

commentatorforall commented

2025-06-29 15:34:49 +00:00

Author

Member

update: sandbox-paths should be left untouched, extra-sandbox-paths should be initalized with the values being present in env.path

update: `sandbox-paths` should be left untouched, `extra-sandbox-paths` should be initalized with the values being present in `env.path`

lix-bot commented

2025-08-05 20:56:07 +00:00

Member

This issue was mentioned on Gerrit on the following CLs:

comment in cl/3333 ("tests/functional2: Make Command Environment actually declarative")

This issue was mentioned on Gerrit on the following CLs: * comment in [cl/3333](https://gerrit.lix.systems/c/lix/+/3333) ("tests/functional2: Make Command Environment actually declarative")

jade commented

2025-08-06 05:22:42 +00:00

Owner

yeah, it should probably be a serializer. idk if it needs to be written into a file, especially, since the env-var does work and has the exact same format. you can if you want, it does no harm.