What are experimental features?
This section describes the notion of experimental features, and how it fits into the big picture of the development of Lix.
Warning
This section has not been updated for Lix development practices and should not be considered authoritative with respect to those; see the Lix wiki for more up-to-date information as it gets written https://wiki.lix.systems/books/lix-contributors. The technical content on this page is correct.
Experimental features are considered unstable, which means that they can be changed or removed at any time. Users must explicitly enable them by toggling the associated experimental feature flags. This allows accessing unstable functionality without unwittingly relying on it.
Experimental feature flags were first introduced in Nix 2.4. Before that, Nix did have experimental features, but they were not guarded by flags and were merely documented as unstable. This was a source of confusion and controversy.
When should a new feature be marked experimental?
A change in the Lix codebase should be guarded by an experimental feature flag if it is considered likely to be reverted or adapted in a backwards-incompatible manner after gathering more experience with it in practice.
Examples:
- Changes to the Nix language, such as new built-ins, syntactic or semantic changes, etc.
- Changes to the command-line interface
Lifecycle of an experimental feature
Experimental features have to be treated on a case-by-case basis. However, the standard workflow for an experimental feature is as follows:
- A new feature is implemented in a pull request
- It is guarded by an experimental feature flag that is disabled by default
- The pull request is merged, the experimental feature ends up in a release
- Using the feature requires explicitly enabling it, signifying awareness of the potential risks
- Being experimental, the feature can still be changed arbitrarily
- The feature can be removed
- The associated experimental feature flag is also removed
- The feature can be declared stable
- The associated experimental feature flag is removed
- There should be enough evidence of users having tried the feature, such as feedback, fixed bugs, demonstrations of how it is put to use
- Maintainers must feel confident that:
- The feature is designed and implemented sensibly, that it is fit for purpose
- Potential interactions are well-understood
- Stabilising the feature will not incur an outsized maintenance burden in the future
The following diagram illustrates the process:
.------.
| idea |
'------'
|
discussion, design, implementation
|
| .-------.
| | |
v v |
.--------------. review
| pull request | |
'--------------' |
| ^ | |
| | '-------'
.---' '----.
| |
merge user feedback,
| (breaking) changes
| |
'---. .----'
| |
v |
+--------------+
.---| experimental |----.
| +--------------+ |
| |
decision to stabilise decision against
| keeping the feature
| |
v v
+--------+ +---------+
| stable | | removed |
+--------+ +---------+
Relation to the RFC process
Experimental features and RFCs both allow approaching substantial changes while minimizing the risk. However they serve different purposes:
- An experimental feature enables developers to iterate on and deliver a new idea without committing to it or requiring a costly long-running fork. It is primarily an issue of implementation, targeting Nix developers and early testers.
- The goal of an RFC is to make explicit all the implications of a change: Explain why it is wanted, which new use-cases it enables, which interface changes it requires, etc. It is primarily an issue of design and communication, targeting the broader community.
This means that experimental features and RFCs are orthogonal mechanisms, and can be used independently or together as needed.
Currently available experimental features
auto-allocate-uids
Allows Nix to automatically pick UIDs for builds, rather than creating
nixbld* user accounts. See the auto-allocate-uids setting for details.
ca-derivations
Allow derivations to be content-addressed in order to prevent rebuilds when changes to the derivation do not result in changes to the derivation's output. See __contentAddressed for details.
cgroups
Allows Nix to execute builds inside cgroups. See
the use-cgroups setting for details.
daemon-trust-override
Allow forcing trusting or not trusting clients with
nix-daemon. This is useful for testing, but possibly also
useful for various experiments with nix-daemon --stdio
networking.
dynamic-derivations
Allow the use of a few things related to dynamic derivations:
-
"text hashing" derivation outputs, so we can build .drv files.
-
dependencies in derivations on the outputs of derivations that are themselves derivations outputs.
fetch-closure
Enable the use of the fetchClosure built-in function in the Nix language.
flakes
Enable flakes. See the manual entry for nix
flake for details.
impure-derivations
Allow derivations to produce non-fixed outputs by setting the
__impure derivation attribute to true. An impure derivation can
have differing outputs each time it is built.
Example:
derivation {
name = "impure";
builder = /bin/sh;
__impure = true; ## mark this derivation as impure
args = [ "-c" "read -n 10 random < /dev/random; echo $random > $out" ];
system = builtins.currentSystem;
}
Each time this derivation is built, it can produce a different
output (as the builder outputs random bytes to $out). Impure
derivations also have access to the network, and only fixed-output
or other impure derivations can rely on impure derivations. Finally,
an impure derivation cannot also be
content-addressed.
This is a more explicit alternative to using builtins.currentTime.
nix-command
Enable the new nix subcommands. See the manual on
nix for details.
no-url-literals
Disallow unquoted URLs as part of the Nix language syntax. The Nix language allows for URL literals, like so:
$ nix repl
Welcome to Nix 2.15.0. Type :? for help.
nix-repl> http://foo
"http://foo"
But enabling this experimental feature will cause the Nix parser to throw an error when encountering a URL literal:
$ nix repl --extra-experimental-features 'no-url-literals'
Welcome to Nix 2.15.0. Type :? for help.
nix-repl> http://foo
error: URL literals are disabled
at «string»:1:1:
1| http://foo
| ^
While this is currently an experimental feature, unquoted URLs are being deprecated and their usage is discouraged.
The reason is that, as opposed to path literals, URLs have no special properties that distinguish them from regular strings, URLs containing parameters have to be quoted anyway, and unquoted URLs may confuse external tooling.
parse-toml-timestamps
Allow parsing of timestamps in builtins.fromTOML.
read-only-local-store
Allow the use of the read-only parameter in local store URIs.
recursive-nix
Allow derivation builders to call Nix, and thus build derivations recursively.
Example:
with import <nixpkgs> {};
runCommand "foo"
{
buildInputs = [ nix jq ];
NIX_PATH = "nixpkgs=${<nixpkgs>}";
}
''
hello=$(nix-build -E '(import <nixpkgs> {}).hello.overrideDerivation (args: { name = "recursive-hello"; })')
mkdir -p $out/bin
ln -s $hello/bin/hello $out/bin/hello
''
An important restriction on recursive builders is disallowing arbitrary substitutions. For example, running
nix-store -r /nix/store/kmwd1hq55akdb9sc7l3finr175dajlby-hello-2.10
in the above runCommand script would be disallowed, as this could
lead to derivations with hidden dependencies or breaking
reproducibility by relying on the current state of the Nix store. An
exception would be if
/nix/store/kmwd1hq55akdb9sc7l3finr175dajlby-hello-2.10 were
already in the build inputs or built by a previous recursive Nix
call.
repl-automation
Makes the repl not use readline/editline, print ENQ (U+0005) when ready for a command, and take commands followed by newline.
repl-flake
Allow passing installables to nix repl, making its interface consistent with the other experimental commands.