Packaging/Quirks and Caveats: Difference between revisions
imported>Lheckemann |
imported>Lheckemann |
||
| Line 34: | Line 34: | ||
Source: [http://stackoverflow.com/questions/43837691/how-to-package-a-single-python-script-with-nix/43837692#43837692 nh2 @ StackOverflow] | Source: [http://stackoverflow.com/questions/43837691/how-to-package-a-single-python-script-with-nix/43837692#43837692 nh2 @ StackOverflow] | ||
A more lightweight alternative is to use <code>nix-shell</code> in the shebang line as described in this [ | A more lightweight alternative is to use <code>nix-shell</code> in the shebang line as described in this [http://iam.travishartwell.net/2015/06/17/nix-shell-shebang/ blog post]. This causes the expression to be evaluated and built every time the script is run; this means that the dependencies will always be kept up to date, but since nix-shell only creates a temporary GC root the dependencies may be removed by a garbage collection, so this approach is not advisable for users who don't have an internet connection available all the time. | ||
== Caveats == | == Caveats == | ||
Revision as of 08:21, 30 August 2017
A good start for packaging your first piece if software is the Quickstart Chapter in the nixpkgs manual Also see the Generic Algorithm on doing Packaging
Build software with Autotools
Add autoreconfHook to buildInputs to automatically build software which uses automake and autoconf:
buildInputs = [ ... autoreconfHook ];
Examples in nixpkgs: * samplicator
Package simple python scripts
For scripts like a single Python file, it is not necessary to specify src in mkDerivation. When you want to use buildPythonPackage the sources need to provide a setup.py file which also is overkill for a lot of projects. The default mkDerivation will attempt to unpack your source code. This can be prevented that by applying unpackPhase = ":"; (: is a no-op in shell scripts).
myscript-package = pkgs.stdenv.mkDerivation {
name = "myscript";
buildInputs = [
(pkgs.python36.withPackages (pythonPackages: with pythonPackages; [
consul
six
requests
]))
];
unpackPhase = ":";
installPhase = "install -m755 -D ${./myscript.py} $out/bin/myscript";
};
stdenv's patchShebangs will automatically replace shebangs in the fixup phase, for ex. #!/usr/bin/env python3 with dependencies given in buildInputs. As the derivation got pkgs.python36.withPackages (...) in buildInputs, it will create a virtualenv-like python wrapper. The python wrapper will have all specified dependencies and will be used to call the script.
In NixOS, the package can be put into environment.systemPackages, and myscript will be available as a global command.
Source: nh2 @ StackOverflow
A more lightweight alternative is to use nix-shell in the shebang line as described in this blog post. This causes the expression to be evaluated and built every time the script is run; this means that the dependencies will always be kept up to date, but since nix-shell only creates a temporary GC root the dependencies may be removed by a garbage collection, so this approach is not advisable for users who don't have an internet connection available all the time.
Caveats
After packaging software and successfully generating an executable some functions of the package might still not work. This is a collection of error and how to fix them:
Fixed by adding wrapGAppsHook to buildInputs:
buildInputs = [ ... wrapGAppsHook ];
Sample PR in nixpkgs:
This can happen when importing python libraries:
Solution: add ${stdenv.cc.cc.lib}/lib/libstdc++.so.6 to the LD_LIBRARY_PATH.