Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add NIX_EXPERIMENTAL_FEATURES environment option #4163

Closed
wants to merge 1 commit into from

Conversation

@kampka
Copy link
Contributor

@kampka kampka commented Oct 18, 2020

This allows for a more portable nix-shell for projects that want to use experimental nix features and versions in their nix-shell without users having to fiddle with their local nix configuration.

@cole-h
Copy link
Member

@cole-h cole-h commented Oct 19, 2020

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

@kampka
Copy link
Contributor Author

@kampka kampka commented Oct 19, 2020

  • 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.

@edolstra
Copy link
Member

@edolstra edolstra commented Oct 19, 2020

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.

@kampka
Copy link
Contributor Author

@kampka kampka commented Oct 19, 2020

@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.

@edolstra
Copy link
Member

@edolstra edolstra commented Oct 19, 2020

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

@FRidh
Copy link
Member

@FRidh FRidh commented Oct 19, 2020

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

@kampka
Copy link
Contributor Author

@kampka kampka commented Oct 19, 2020

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.

@regnat
Copy link
Contributor

@regnat regnat commented Oct 20, 2020

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)

@kampka
Copy link
Contributor Author

@kampka kampka commented Oct 22, 2020

Closing this in favor of #4166

@kampka kampka closed this Oct 22, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Linked issues

Successfully merging this pull request may close these issues.

None yet

5 participants