Import From Derivation: Difference between revisions

Line 66:

Some examples of IFD can be seen when using nixpkgs to fetch a specific

version of nixpkgs, and then importing the source.

IFD is a powerful feature, but it should be avoided _if possible_. IFD extends the duration of evaluation, which is single threaded and it affects the predictions of the `nix` progress bar.

Acceptable uses of IFD include importing a pinned nixpkgs and automation around lock files. Such uses vastly improve your development workflow, outweighing the slight disadvantages of IFD.

As a rule of thumb, if you can avoid IFD by refactoring Nix code or moving your build logic into the derivations themselves, you should do so.

<h2>Recognizing IFD</h2>

The textbook case of IFD looks like `import e` where `e` is an expression that requires a build to provide the value. However, `import` is not the only function that can require a build. For example, `builtins.readFile` can have the same effect.

All functions that query the filesystem will require a build when invoked on a derivation output path or subpath. This has the same effect and is therefore also called IFD. These include

* <code>import</code>

* <code>builtins.readFile</code>

* <code>builtins.readDir</code>

* <code>builtins.pathExists</code>

* <code>builtins.filterSource</code>

* <code>builtins.path</code>

* <code>builtins.hashFile</code>

* <code>builtins.scopedImport</code>

* potentially other functions if those read the filesystem in any way

* '''library functions''' that invoke the above

@@ Line 66: / Line 66: @@
 Some examples of IFD can be seen when using nixpkgs to fetch a specific
 version of nixpkgs, and then importing the source.
+<h2>When to use IFD</h2>
+IFD is a powerful feature, but it should be avoided _if possible_. IFD extends the duration of evaluation, which is single threaded and it affects the predictions of the `nix` progress bar.
+Acceptable uses of IFD include importing a pinned nixpkgs and automation around lock files. Such uses vastly improve your development workflow, outweighing the slight disadvantages of IFD.
+As a rule of thumb, if you can avoid IFD by refactoring Nix code or moving your build logic into the derivations themselves, you should do so.
+<h2>Recognizing IFD</h2>
+The textbook case of IFD looks like `import e` where `e` is an expression that requires a build to provide the value. However, `import` is not the only function that can require a build. For example, `builtins.readFile` can have the same effect.
+All functions that query the filesystem will require a build when invoked on a derivation output path or subpath. This has the same effect and is therefore also called IFD. These include
+* <code>import</code>
+* <code>builtins.readFile</code>
+* <code>builtins.readDir</code>
+* <code>builtins.pathExists</code>
+* <code>builtins.filterSource</code>
+* <code>builtins.path</code>
+* <code>builtins.hashFile</code>
+* <code>builtins.scopedImport</code>
+* potentially other functions if those read the filesystem in any way
+* '''library functions''' that invoke the above