aboutsummaryrefslogtreecommitdiff
path: root/tests/functional/experimental-features.sh
AgeCommit message (Collapse)Author
2024-06-30libexpr/flake: allow automatic rejection of configuration options from flakesAlois Wohlschlager
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-05-03Rename `nix show-config` to `nix config show`Théophane Hufschmitt
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-12-01Put functional tests in `tests/functional`John Ericson
I think it is bad for these reasons when `tests/` contains a mix of functional and integration tests - Concepts is harder to understand, the documentation makes a good unit vs functional vs integration distinction, but when the integration tests are just two subdirs within `tests/` this is not clear. - Source filtering in the `flake.nix` is more complex. We need to filter out some of the dirs from `tests/`, rather than simply pick the dirs we want and take all of them. This is a good sign the structure of what we are trying to do is not matching the structure of the files. With this change we have a clean: ```shell-session $ git show 'HEAD:tests' tree HEAD:tests functional/ installer/ nixos/ ``` (cherry picked from commit 68c81c737571794f7246db53fb4774e94fcf4b7e)