scriptis/lix
0
0
Fork 0
forked from lix-project/lix
Code Pull requests Activity
lix/tests/functional/experimental-features.sh

87 lines
3.7 KiB
Bash
Raw Permalink Normal View History

Write test, will fail until rest of PR
2023-01-17 00:10:18 +00:00
source common.sh
Do not gate or hide experimental settings 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
2023-04-11 14:46:38 +00:00
# Skipping these two for now, because we actually *do* want flags and
# config settings to always show up in the manual, just be marked
# experimental. Will reenable once the manual generation takes advantage
# of the JSON metadata on this.
#
# # Without flakes, flake options should not show up
# # With flakes, flake options should show up
#
# function grep_both_ways {
# nix --experimental-features 'nix-command' "$@" | grepQuietInverse flake
# nix --experimental-features 'nix-command flakes' "$@" | grepQuiet flake
#
# # Also, the order should not matter
# nix "$@" --experimental-features 'nix-command' | grepQuietInverse flake
# nix "$@" --experimental-features 'nix-command flakes' | grepQuiet flake
# }
#
# # Simple case, the configuration effects the running command
# grep_both_ways show-config
#
# # Medium case, the configuration effects --help
# grep_both_ways store gc --help
Write test, will fail until rest of PR
2023-01-17 00:10:18 +00:00
Fix some issues with experimental config settings 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>
2023-04-10 02:39:04 +00:00
# Test settings that are gated on experimental features; the setting is ignored
# with a warning if the experimental feature is not enabled. The order of the
# `setting = value` lines in the configuration should not matter.
# 'flakes' experimental-feature is disabled before, ignore and warn
NIX_CONFIG='
experimental-features = nix-command
accept-flake-config = true
Rename `nix show-config` to `nix config show` Part of #7672 My main motivation is to be able to use `nix.checkConfig`[1]. This doesn't work with Lix currently since the module uses `nix show-config` if the Nix version is <2.20pre and `nix config show` otherwise. I think this is the only instance where nixpkgs checks for which Nix commands exist that affects us now, so I figured we could just perform the rename here as well[2] and still provide the current version number[3]. I don't have a strong opinion on whether to deprecate `nix show-config`, the warning is added there automatically. (cherry picked from commit f300e11b056dea414d7d77bbc6e5a7dc5d9ddd41) [1] https://nixos.org/manual/nixos/stable/options.html#opt-nix.checkConfig [2] I should add that I don't use the "official" ways of installing Lix because using the flake directly and callPackaging it seemed to fit better into my workflow: I already have a little mess to make sure Hydra from the flake uses the correct pkgs.nix and I didn't want to complicate it further while keeping a single package-set I can build in CI. Don't get me wrong, I think such a module for a quick-start is very important, just giving context on why I bother in the first place :) [3] When we go public, I think it's worth considering to add support in nixpkgs itself for Lix. Change-Id: I47b4239b05cbeda3c370d2fa56ea768b768768ac
2023-11-27 18:41:30 +00:00
' nix config show accept-flake-config 1>$TEST_ROOT/stdout 2>$TEST_ROOT/stderr
libexpr/flake: allow automatic rejection of configuration options from flakes The `allow-flake-configuration` option allows the user to control whether to accept configuration options supplied by flakes. Unfortunately, setting this to false really meant "ask each time" (with an option to remember the choice for each specific option encountered). Let no mean no, and introduce (and default to) a separate value for the "ask each time" behaviour. Co-Authored-By: Jade Lovelace <lix@jade.fyi> Change-Id: I7ccd67a95bfc92cffc1ebdc972d243f5191cc1b4
2024-06-29 18:23:17 +00:00
grepQuiet "ask" $TEST_ROOT/stdout
Fix some issues with experimental config settings 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>
2023-04-10 02:39:04 +00:00
grepQuiet "Ignoring setting 'accept-flake-config' because experimental feature 'flakes' is not enabled" $TEST_ROOT/stderr
# 'flakes' experimental-feature is disabled after, ignore and warn
NIX_CONFIG='
accept-flake-config = true
experimental-features = nix-command
Rename `nix show-config` to `nix config show` Part of #7672 My main motivation is to be able to use `nix.checkConfig`[1]. This doesn't work with Lix currently since the module uses `nix show-config` if the Nix version is <2.20pre and `nix config show` otherwise. I think this is the only instance where nixpkgs checks for which Nix commands exist that affects us now, so I figured we could just perform the rename here as well[2] and still provide the current version number[3]. I don't have a strong opinion on whether to deprecate `nix show-config`, the warning is added there automatically. (cherry picked from commit f300e11b056dea414d7d77bbc6e5a7dc5d9ddd41) [1] https://nixos.org/manual/nixos/stable/options.html#opt-nix.checkConfig [2] I should add that I don't use the "official" ways of installing Lix because using the flake directly and callPackaging it seemed to fit better into my workflow: I already have a little mess to make sure Hydra from the flake uses the correct pkgs.nix and I didn't want to complicate it further while keeping a single package-set I can build in CI. Don't get me wrong, I think such a module for a quick-start is very important, just giving context on why I bother in the first place :) [3] When we go public, I think it's worth considering to add support in nixpkgs itself for Lix. Change-Id: I47b4239b05cbeda3c370d2fa56ea768b768768ac
2023-11-27 18:41:30 +00:00
' nix config show accept-flake-config 1>$TEST_ROOT/stdout 2>$TEST_ROOT/stderr
libexpr/flake: allow automatic rejection of configuration options from flakes The `allow-flake-configuration` option allows the user to control whether to accept configuration options supplied by flakes. Unfortunately, setting this to false really meant "ask each time" (with an option to remember the choice for each specific option encountered). Let no mean no, and introduce (and default to) a separate value for the "ask each time" behaviour. Co-Authored-By: Jade Lovelace <lix@jade.fyi> Change-Id: I7ccd67a95bfc92cffc1ebdc972d243f5191cc1b4
2024-06-29 18:23:17 +00:00
grepQuiet "ask" $TEST_ROOT/stdout
Fix some issues with experimental config settings 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>
2023-04-10 02:39:04 +00:00
grepQuiet "Ignoring setting 'accept-flake-config' because experimental feature 'flakes' is not enabled" $TEST_ROOT/stderr
# 'flakes' experimental-feature is enabled before, process
NIX_CONFIG='
experimental-features = nix-command flakes
accept-flake-config = true
Rename `nix show-config` to `nix config show` Part of #7672 My main motivation is to be able to use `nix.checkConfig`[1]. This doesn't work with Lix currently since the module uses `nix show-config` if the Nix version is <2.20pre and `nix config show` otherwise. I think this is the only instance where nixpkgs checks for which Nix commands exist that affects us now, so I figured we could just perform the rename here as well[2] and still provide the current version number[3]. I don't have a strong opinion on whether to deprecate `nix show-config`, the warning is added there automatically. (cherry picked from commit f300e11b056dea414d7d77bbc6e5a7dc5d9ddd41) [1] https://nixos.org/manual/nixos/stable/options.html#opt-nix.checkConfig [2] I should add that I don't use the "official" ways of installing Lix because using the flake directly and callPackaging it seemed to fit better into my workflow: I already have a little mess to make sure Hydra from the flake uses the correct pkgs.nix and I didn't want to complicate it further while keeping a single package-set I can build in CI. Don't get me wrong, I think such a module for a quick-start is very important, just giving context on why I bother in the first place :) [3] When we go public, I think it's worth considering to add support in nixpkgs itself for Lix. Change-Id: I47b4239b05cbeda3c370d2fa56ea768b768768ac
2023-11-27 18:41:30 +00:00
' nix config show accept-flake-config 1>$TEST_ROOT/stdout 2>$TEST_ROOT/stderr
Fix some issues with experimental config settings 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>
2023-04-10 02:39:04 +00:00
grepQuiet "true" $TEST_ROOT/stdout
grepQuietInverse "Ignoring setting 'accept-flake-config'" $TEST_ROOT/stderr
# 'flakes' experimental-feature is enabled after, process
NIX_CONFIG='
accept-flake-config = true
experimental-features = nix-command flakes
Rename `nix show-config` to `nix config show` Part of #7672 My main motivation is to be able to use `nix.checkConfig`[1]. This doesn't work with Lix currently since the module uses `nix show-config` if the Nix version is <2.20pre and `nix config show` otherwise. I think this is the only instance where nixpkgs checks for which Nix commands exist that affects us now, so I figured we could just perform the rename here as well[2] and still provide the current version number[3]. I don't have a strong opinion on whether to deprecate `nix show-config`, the warning is added there automatically. (cherry picked from commit f300e11b056dea414d7d77bbc6e5a7dc5d9ddd41) [1] https://nixos.org/manual/nixos/stable/options.html#opt-nix.checkConfig [2] I should add that I don't use the "official" ways of installing Lix because using the flake directly and callPackaging it seemed to fit better into my workflow: I already have a little mess to make sure Hydra from the flake uses the correct pkgs.nix and I didn't want to complicate it further while keeping a single package-set I can build in CI. Don't get me wrong, I think such a module for a quick-start is very important, just giving context on why I bother in the first place :) [3] When we go public, I think it's worth considering to add support in nixpkgs itself for Lix. Change-Id: I47b4239b05cbeda3c370d2fa56ea768b768768ac
2023-11-27 18:41:30 +00:00
' nix config show accept-flake-config 1>$TEST_ROOT/stdout 2>$TEST_ROOT/stderr
Fix some issues with experimental config settings 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>
2023-04-10 02:39:04 +00:00
grepQuiet "true" $TEST_ROOT/stdout
grepQuietInverse "Ignoring setting 'accept-flake-config'" $TEST_ROOT/stderr
function exit_code_both_ways {
expect 1 nix --experimental-features 'nix-command' "$@" 1>/dev/null
nix --experimental-features 'nix-command flakes' "$@" 1>/dev/null
# Also, the order should not matter
expect 1 nix "$@" --experimental-features 'nix-command' 1>/dev/null
nix "$@" --experimental-features 'nix-command flakes' 1>/dev/null
}
exit_code_both_ways show-config --flake-registry 'https://no'
Punt on improper global flags for now See the note in the test. We don't want these flags showing up for commands where they are irrelevant. Eventually, this needs a proper fix, but it need not be a blocker for stabilize: for a quick-n-dirty punt, just put these flags behind the `nix-command` unstable feature. This is fine because they are only relevant for commands which we don't need to stabilize for a while.
2023-01-17 00:48:39 +00:00
Stuctured command stability Prior to this, there was an ad-hoc whitelist in `main.cc`. Now, every command states its stability. In a future PR, we will adjust the manual to take advantage of this new information in the JSON. (It will be easier to do that once we have some experimental feature docs to link too; see #5930 and #7798.)
2023-01-17 04:01:18 +00:00
# Double check these are stable
Fix some issues with experimental config settings 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>
2023-04-10 02:39:04 +00:00
nix --experimental-features '' --help 1>/dev/null
nix --experimental-features '' doctor --help 1>/dev/null
nix --experimental-features '' repl --help 1>/dev/null
nix --experimental-features '' upgrade-nix --help 1>/dev/null
Punt on improper global flags for now See the note in the test. We don't want these flags showing up for commands where they are irrelevant. Eventually, this needs a proper fix, but it need not be a blocker for stabilize: for a quick-n-dirty punt, just put these flags behind the `nix-command` unstable feature. This is fine because they are only relevant for commands which we don't need to stabilize for a while.
2023-01-17 00:48:39 +00:00
# These 3 arguments are currently given to all commands, which is wrong (as not
# all care). To deal with fixing later, we simply make them require the
# nix-command experimental features --- it so happens that the commands we wish
# stabilizing to do not need them anyways.
for arg in '--print-build-logs' '--offline' '--refresh'; do
Fix some issues with experimental config settings 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>
2023-04-10 02:39:04 +00:00
nix --experimental-features 'nix-command' "$arg" --help 1>/dev/null
expect 1 nix --experimental-features '' "$arg" --help 1>/dev/null
Punt on improper global flags for now See the note in the test. We don't want these flags showing up for commands where they are irrelevant. Eventually, this needs a proper fix, but it need not be a blocker for stabilize: for a quick-n-dirty punt, just put these flags behind the `nix-command` unstable feature. This is fine because they are only relevant for commands which we don't need to stabilize for a while.
2023-01-17 00:48:39 +00:00
done
Copy permalink