What does this improve over the --experimental-features command line flag? (Note: all settings have a matching --<kebab-case-setting-name> flag.)

• It allows to enable experimental features via nix-shell shellHook. These settings will then be tracked in git, are more or less project specific and users do not require additional steps and knowledge to activate them. This is probably equivalent to adding a nix.conf file to your project and set NIX_USER_CONF_FILES appropriately, without the risk of messing up the users local settings if something is missed, as NIX_USER_CONF_FILES does not work cumulatively with eg. XDG config locations automatically.

• It has to be set only once, meaning that all tooling in the project can just us it / rely on it without having to put and maintain a long-ish --experimental-features "nix-command flakes recursive-nix ca-derivations" in every invocation.

Maybe it's better to add a generic environment variable for passing Nix options, e.g. NIX_CONFIG="experimental-features = nix-command flakes". That seems preferable over adding ad hoc environment variables for specific options.

@edolstra What would be your preferred separator for such generic options? I have to little knowledge of nix options to know about whats already being used.

'\n'. Then we can just treat the contents of the environment variable as a configuration file.

Could one then not just as easily include the Nix configuration file in the project repo and export NIX_CONF_DIR from the shellHook.

Could one then not just as easily include the Nix configuration file in the project repo and export NIX_CONF_DIR from the shellHook.

The nix configuration file as such is not really portable as such, if you think about options like cores or the builder* options. As such, I don't see a project specific nix.conf as really desirable to have if you just need very specific overrides.

Could one then not just as easily include the Nix configuration file in the project repo and export NIX_CONF_DIR from the shellHook.

The nix configuration file as such is not really portable as such, if you think about options like cores or the builder* options. As such, I don't see a project specific nix.conf as really desirable to have if you just need very specific overrides.

Ftr, nix also honors XDG_CONFIG_DIRS (see https://hydra.nixos.org/build/128710737/download/1/manual/command-ref/conf-file.html?highlight=XDG_CONFIG_DIRS#description), so it's possible to prepend it a directory containing a nix/nix.conf file, in which case it will be loaded in addition to the other ones.

(There's also NIX_USER_CONF_FILES, but setting it will disable the xdg-based heuristic for finding user conf files, which is likely to cause troubles)

Closing this in favor of #4166