Development environment with nix-shell: Difference between revisions

imported>Bensleveritt
m Fixes minor typos, and edits for readablilty
imported>Ericson2314
Tweak examples to be "cross compliant" and add a few notes why.
Line 7: Line 7:
{ pkgs ? import <nixpkgs> {} }:
{ pkgs ? import <nixpkgs> {} }:
   pkgs.mkShell {
   pkgs.mkShell {
     buildInputs = [ pkgs.ruby_2_3 ];
     # nativeBuildInputs is usually what you want -- tools you need to run
    nativeBuildInputs = [ pkgs.buildPackages.ruby_2_3 ];
}
}
</syntaxHighlight>
</syntaxHighlight>
Line 29: Line 30:
{ pkgs ? import <nixpkgs> {} }:
{ pkgs ? import <nixpkgs> {} }:
pkgs.mkShell {
pkgs.mkShell {
  # buildInputs is for dependencies you'd need "at run time",
  # were you to to use nix-build not nix-shell and build whatever you were working on
   buildInputs = [
   buildInputs = [
     (import ./my-expression.nix { inherit pkgs; })
     (import ./my-expression.nix { inherit pkgs; })
Line 34: Line 37:
}
}
</syntaxHighlight>
</syntaxHighlight>
=== Small cross env note ===
The comments in the code snippets on <code>nativeBuildInputs</code> and <code>buildInputs</code> above might seem pendantic --- who cares about build-time vs run-time when we're just making a dev environment, not a real package! However, the distinction becomes of practical importance if one wants a cross compilation development environment. In that case one would begin file with something like:
<syntaxHighlight lang=nix>
{ pkgs ? import <nixpkgs> { crossSystem.config = "exotic_arch-unknown-exotic_os"; } }:
</syntaxHighlight>
and <code>nativeBuildInputs</code> would be for the native platform, while <code>buildInputs</code> would be for the foreign platform. That's a much more practical distinction: any tool that's miscategorized one won't be able to run, and any library that's miscategorized one won't be able to link!


== Using Direnv ==
== Using Direnv ==