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]]. | ||
=== | === 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! | ||
== | == 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;-)). | ||