Development environment with nix-shell: Difference between revisions

imported>Ncfavier
m fix typo 'pendantic'
imported>Milahu
add stdenv.mkDerivation
Line 40: Line 40:
If you want to see how to manually run the various phases of a given derivation from a nix-shell (useful to debug), see [[Nixpkgs/Create_and_debug_packages#Using_nix-shell_for_package_development]].  
If you want to see how to manually run the various phases of a given derivation from a nix-shell (useful to debug), see [[Nixpkgs/Create_and_debug_packages#Using_nix-shell_for_package_development]].  


=== Small cross env note ===
=== stdenv.mkDerivation ===
 
Let's assume you have a <code>default.nix</code> file
 
<syntaxHighlight lang=nix>
{ stdenv, python }:
stdenv.mkDerivation {
  buildInputs = [ python ];
  name = "some-package";
  version = "0.0.1";
  src = /can/be/a/local/path;
}
</syntaxHighlight>
 
Then you can start a development shell with
 
<syntaxHighlight lang=bash>
nix-shell -E 'with import <nixpkgs> { }; callPackage ./default.nix { }'
</syntaxHighlight>
 
In this shell, you can run the phases of stdenv.mkDerivation:
 
<syntaxHighlight lang=bash>
cd $(mktemp -d) && \
unpackPhase && \
cd * && \
configurePhase && \
buildPhase && \
checkPhase && \
installPhase && \
fixupPhase
</syntaxHighlight>
 
=== cross env ===


The comments in the code snippets on <code>nativeBuildInputs</code> and <code>buildInputs</code> above might seem pedantic --- 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:
The comments in the code snippets on <code>nativeBuildInputs</code> and <code>buildInputs</code> above might seem pedantic --- 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:
Line 48: Line 81:
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!
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 ==
== direnv ==


One of the limitations of nix-shell is that you can't use a shell other than bash. Thankfully, there is Direnv [[https://direnv.net/]] with the support of Nix[[https://github.com/direnv/direnv/wiki/Nix]] to overcome this limitation. Also, Direnv provides some nice features like loading the environment automatically when you enter your project directory and show the loaded variables to you (explicit is always better;-)).
One of the limitations of nix-shell is that you can't use a shell other than bash. Thankfully, there is Direnv [[https://direnv.net/]] with the support of Nix[[https://github.com/direnv/direnv/wiki/Nix]] to overcome this limitation. Also, Direnv provides some nice features like loading the environment automatically when you enter your project directory and show the loaded variables to you (explicit is always better;-)).