Flakes: Difference between revisions

Line 571:

</syntaxHighlight>

=== Rapid iteration of a direct dependency ===

One common pain point with using Nix as a development environment is the need to completely rebuild dependencies and re-enter the dev shell every time they are updated. The <code>nix develop --redirect <flake> <directory></code> command allows you to provide a mutable dependency to your shell as if it were built by Nix.

Consider a situation where your executable, <code>consumexe</code>, depends on a library, <code>libdep</code>. You're trying to work on both at the same time, where changes to <code>libdep</code> are reflected in real time for <code>consumexe</code>. This workflow can be achieved like so:

cd ~/libdep-src-checkout/

nix develop # Or `nix-shell` if applicable.

export prefix="./install" # configure nix to install it here

buildPhase # build it like nix does

installPhase # install it like nix does

</syntaxHighlight>

Now that you've built the dependency, <code>consumexe</code> can take it as an input. '''In another terminal''':

cd ~/consumexe-src-checkout/

nix develop --redirect libdep ~/libdep-src-checkout/install

echo $buildInputs | tr " " "\n" | grep libdep

# Output should show ~/libdep-src-checkout/ so you know it worked

</syntaxHighlight>

If Nix warns you that your redirected flake isn't actually used as an input to the evaluated flake, try using the `--inputs-from .` flag. If all worked well you should be able to <code>buildPhase && installPhase</code> when the dependency changes and rebuild your consumer with the new version _without_ exiting the development shell.

== See also ==

@@ Line 571: / Line 571: @@
 </syntaxHighlight>
+=== Rapid iteration of a direct dependency ===
+One common pain point with using Nix as a development environment is the need to completely rebuild dependencies and re-enter the dev shell every time they are updated. The <code>nix develop --redirect <flake> <directory></code> command allows you to provide a mutable dependency to your shell as if it were built by Nix.
+Consider a situation where your executable, <code>consumexe</code>, depends on a library, <code>libdep</code>. You're trying to work on both at the same time, where changes to <code>libdep</code> are reflected in real time for <code>consumexe</code>. This workflow can be achieved like so:
+<syntaxHighlight lang=bash>
+cd ~/libdep-src-checkout/
+nix develop # Or `nix-shell` if applicable.
+export prefix="./install" # configure nix to install it here
+buildPhase   # build it like nix does
+installPhase # install it like nix does
+</syntaxHighlight>
+Now that you've built the dependency, <code>consumexe</code> can take it as an input. '''In another terminal''':
+<syntaxHighlight lang=bash>
+cd ~/consumexe-src-checkout/
+nix develop --redirect libdep ~/libdep-src-checkout/install
+echo $buildInputs | tr " " "\n" | grep libdep
+# Output should show ~/libdep-src-checkout/ so you know it worked
+</syntaxHighlight>
+If Nix warns you that your redirected flake isn't actually used as an input to the evaluated flake, try using the `--inputs-from .` flag. If all worked well you should be able to <code>buildPhase && installPhase</code> when the dependency changes and rebuild your consumer with the new version _without_ exiting the development shell.
 == See also ==