Nixpkgs/Create and debug packages: Difference between revisions

imported>Mausch
mNo edit summary
imported>Milahu
add nix-shell, use more bullet points, add links to manual and nix pills, prettify links, use git shallow clone
Line 1: Line 1:
This article describes how to work with the nix related repositories to add new packages, edit and debug existing packages. For details on the NixOS module system see [[NixOS:Modules]]. [[NixOS:extend_NixOS]] explains how to write, test and debug your own modules.
This article describes how to work with the nix related repositories to add new packages, edit and debug existing packages. For details on the NixOS module system see [[NixOS:Modules]]. [[NixOS:extend_NixOS]] explains how to write, test and debug your own modules.


There is a chapter about hacking packages and modules in the NixOS manual: http://nixos.org/nixos/manual/index.html#ch-development
There is a chapter about hacking packages and modules in the NixOS manual: [http://nixos.org/nixos/manual/index.html#ch-development development]


Writing packages is covered in https://nixos.org/manual/nixpkgs/stable/#chap-quick-start and writing modules in http://nixos.org/nixos/manual
Writing packages is covered in [https://nixos.org/manual/nixpkgs/stable/#chap-quick-start quick start] and writing modules is covered in the [http://nixos.org/nixos/manual manual]


If you've read the manual and still don't know how to go about creating a package read on.
If you've read the manual and still don't know how to go about creating a package, read on.


The nix repositories are hosted here: https://github.com/nixos
The nix repositories are hosted at https://github.com/NixOS




== Basics ==
== Basics ==
The code for nix packages is managed in the nixpkgs repository. NixOS services, and other system configuration options are managed in the nixos sub-directory of the nixpkgs repository.
The code for nix packages is managed in the [https://github.com/NixOS/nixpkgs/tree/master/pkgs nixpkgs/pkgs] repository. NixOS services, and other system configuration options are managed in [https://github.com/NixOS/nixpkgs/tree/master/nixos nixpkgs/nixos].


The steps to take for your first change should look something like this:
The steps to take for your first change should look something like this:


# Fork the repo (e.g. click the fork button on https://github.com/nixos/nixpkgs).
# Fork the repo (e.g. click the fork button on https://github.com/nixos/nixpkgs).
# Clone your fork <code>git clone git@github.com:YOUR-GITHUB-ACCOUNT-NAME/nixpkgs.git</code>
# Clone your fork <code>git clone --depth 1 https://github.com/YOUR-GITHUB-ACCOUNT-NAME/nixpkgs.git</code>
# Hack hack hack
# Hack hack hack
# Push your changes to your fork
# Push your changes to your fork
Line 30: Line 30:
=== Packages from source code ===
=== Packages from source code ===


# Read the repo build instructions. Many times the instructions won't be 100% clear in the README, but there might be some script for CI that will be more precise. This should give you a rough idea of how hard it will be to package it. For example, if it uses a standard, vanilla build, it will probably be easy to package. If on the contrary there are no CI scripts, or no build instructions, or the build instructions are complicated, things could be rough.  
# Read the repo build instructions. Many times the instructions won't be 100% clear in the README, but there might be some script for CI that will be more precise. This should give you a rough idea of how hard it will be to package it. For example, if it uses a standard, vanilla build (<code>./configure && make && make install</code>), it will probably be easy to package. If on the contrary there are no CI scripts, or no build instructions, or the build instructions are complicated, things could be rough.  
# Look in nixpkgs for a similar package to use as reference. Many times you can just copy/paste a similar package, change the <code>src</code> attribute and things will just work. E.g. if you're packaging a project written in Go, find a package for an existing Go application. Each language has its own supporting Nix functions and a more or less standard way of dealing with things. For example Go has <code>buildGoPackage</code>. Rust has <code>buildRustPackage</code>. Python has <code>buildPythonApplication</code>. The official documentation for these is generally good. These functions will typically do most of the heavy lifting and you probably just have to point them to the repo and they will do the rest. There are also specific functions for wrapping e.g. GNOME applications. It pays off to have a look at the [https://nixos.org/manual/nixpkgs/stable/#chap-language-support table of contents for these functions in the docs].  
# Look in nixpkgs for a similar package to use as reference. Many times you can just copy/paste a similar package, change the <code>src</code> attribute and things will just work. E.g. if you're packaging a project written in Go, find a package for an existing Go application. Each language has its own supporting Nix functions and a more or less standard way of dealing with things. For example [https://nixos.org/manual/nixpkgs/stable/#sec-language-go Go] has <code>buildGoModule</code>. [https://nixos.org/manual/nixpkgs/stable/#rust Rust] has <code>buildRustPackage</code>. [https://nixos.org/manual/nixpkgs/stable/#python Python] has <code>buildPythonApplication</code>. [https://nixos.org/manual/nixpkgs/stable/#node.js Node.js] has <code>node2nix</code>, <code>yarn2nix</code>, etc. The official documentation for these is generally good. These functions will typically do most of the heavy lifting and you probably just have to point them to the repo and they will do the rest. There are also specific functions for wrapping e.g. [https://nixos.org/manual/nixpkgs/stable/#sec-language-gnome GNOME] applications (<code>wrapGAppsHook</code>), or [https://nixos.org/manual/nixpkgs/stable/#sec-language-qt Qt] apps (<code>libsForQt5</code>, <code>wrapQtAppsHook</code>). It pays off to have a look at these functions in the [https://nixos.org/manual/nixpkgs/stable/#chap-language-support language-support table in the NixOS manual].  
# If there isn't a specific function for the build/language you'll need to use stdenv.mkDerivation directly but don't despair (yet!). mkDerivation has built-in support for GNU make, CMake, and possibly others too (?) so you probably won't have to spell out every single command necessary to build the project.
# If there isn't a specific function for the build/language you'll need to use [https://nixos.org/guides/nix-pills/fundamentals-of-stdenv.html#idm140737319559808 stdenv.mkDerivation] directly but don't despair (yet!). mkDerivation has built-in support for GNU make, CMake, and possibly others too (?) so you probably won't have to spell out every single command necessary to build the project.
# Figure out at least some dependencies from the project repo. Doesn't have to be perfect, but something to get you started. See if they're available in nixpkgs. If any dependency is missing you'll need to package that as well! Common libraries are usually available though.
# Figure out at least some dependencies from the project repo. Doesn't have to be perfect, but something to get you started. See if they're available in nixpkgs (<code>nix search some-library</code> or <code>nix-locate lib/somelibrary.so</code>). If any dependency is missing you'll need to package that as well! Common libraries are usually available though.
# Prototype / iterate the build with nix-shell. Run <code>nix-shell -p dep1 dep2 dep3...</code> then run the build manually on the command line. Hopefully this will let you quickly identify missing dependencies and maybe some build quirks. Again this doesn't need to be perfect, don't spend too much time on this.
# Prototype / iterate the build with nix-shell. Run <code>nix-shell -p dep1 dep2 dep3...</code> then run the build manually on the command line. Hopefully this will let you quickly identify missing dependencies and maybe some build quirks. Again this doesn't need to be perfect, don't spend too much time on this.
# Write the default.nix. <br/>
# Write the default.nix file, save it in some empty local directory.
Do it in some empty local directory and at the top just say <code>with import <nixpkgs> {};</code>, don't worry too much about declaring every dependency as a parameter for now as it will only slow you down. Again, use some similar package as reference.
# At the top of default.nix add <code>with import <nixpkgs> {};</code>. For now, don't worry too much about declaring every dependency as a parameter<!-- TODO clarify. "parameter of the default build function"? -->, as it will only slow you down. Again, use some similar package as reference.
# Build it with <code>nix build -L</code>. Iterate on tweaking default.nix and running nix build until it builds. At this stage you will start dealing with build quirks of the project, if the are any. Compile-time errors will hopefully point out what you're missing. For example [https://github.com/NixOS/nixpkgs/blob/643ce4bd0f057bc0b90f0faebeb83a3b14f01674/pkgs/tools/package-management/micromamba/default.nix#L6-L10 micromamba needs a specialized build of libsolv].
# Build the package with <code>nix build -L</code>. Iterate on tweaking default.nix and running nix build until it builds.
# Instead of nix build, for large projects with long compile times, you can use [[Development environment with nix-shell|nix-shell]] with <code>nix shell -L</code> (same arguments as nix build). Inside the nix-shell, run something like <code>cd $(mktemp -d) && unpackPhase && cd * && configurePhase && buildPhase && checkPhase && installPhase && fixupPhase</code> (these are the phases of [https://nixos.org/guides/nix-pills/fundamentals-of-stdenv.html stdenv.mkDerivation])
# At this stage, you may encounter some build-quirks of the project. Compile-time errors will hopefully explain what you're missing. For example [https://github.com/NixOS/nixpkgs/blob/643ce4bd0f057bc0b90f0faebeb83a3b14f01674/pkgs/tools/package-management/micromamba/default.nix#L6-L10 micromamba needs a specialized build of libsolv].
# Read on below for further steps.
# Read on below for further steps.


Line 43: Line 45:


# There's probably a package for it for some other distro. Use that package definition to figure out the dependencies. For example, if you have a deb package you can view its dependencies by running <code>dpkg -I <package.deb></code>. [https://aur.archlinux.org/packages/ Arch packages] can also be useful to look up for reference (view the package's PKGBUILD):
# There's probably a package for it for some other distro. Use that package definition to figure out the dependencies. For example, if you have a deb package you can view its dependencies by running <code>dpkg -I <package.deb></code>. [https://aur.archlinux.org/packages/ Arch packages] can also be useful to look up for reference (view the package's PKGBUILD):
# Sometimes the definitions for other distros won't be enough by nix's standards. If that's the case, use <code>ldd</code> and/or <code>strace</code> to find the rest of the dependencies. If you're not familiar with <code>ldd</code>/<code>strace</code> see https://unix.stackexchange.com/questions/120015/how-to-find-out-the-dynamic-libraries-executables-loads-when-run
# Sometimes the definitions for other distros won't be enough by nix's standards. If that's the case, use <code>ldd</code> and/or <code>strace</code> to find the rest of the dependencies. If you're not familiar with <code>ldd</code>/<code>strace</code> see [https://unix.stackexchange.com/questions/120015/how-to-find-out-the-dynamic-libraries-executables-loads-when-run How to find out the dynamic libraries executables loads when run?]
# See how other nix binary packages deal with dependencies. For example [https://github.com/NixOS/nixpkgs/search?q=%22dpkg+-x%22 nix packages based on deb packages].
# See how other nix binary packages deal with dependencies. For example [https://github.com/NixOS/nixpkgs/search?q=%22dpkg+-x%22 nix packages based on deb packages].
# If the application contains some helper executable or vendored dlopen'd library you will probably need to give the nix treatment to it as well. For example, [https://github.com/NixOS/nixpkgs/blob/42c154d332eb4eb17c74b587c1d4c2fcc3042ba1/pkgs/applications/editors/jetbrains/default.nix#L196-L200 JetBrains Rider vendors dotnet so it needs to be replaced with the dotnet nix package].
# If the application contains some helper executable or vendored dlopen'd library you will probably need to give the nix treatment to it as well. For example, [https://github.com/NixOS/nixpkgs/blob/42c154d332eb4eb17c74b587c1d4c2fcc3042ba1/pkgs/applications/editors/jetbrains/default.nix#L196-L200 JetBrains Rider vendors dotnet so it needs to be replaced with the dotnet nix package].
Line 51: Line 53:


# Once you have the package building successfully, it's time to start testing the output. Run <code>nix run -L</code>, this will give you a shell where the application executable should be in the PATH. If the executable is not in the PATH, you might need to override <code>installPhase</code>. Try to test as many functions of the application as you can. Most of the time only making sure that the application starts up will not be enough.
# Once you have the package building successfully, it's time to start testing the output. Run <code>nix run -L</code>, this will give you a shell where the application executable should be in the PATH. If the executable is not in the PATH, you might need to override <code>installPhase</code>. Try to test as many functions of the application as you can. Most of the time only making sure that the application starts up will not be enough.
# Now that your package builds and runs, it's time to move it to nixpkgs. Read https://github.com/NixOS/nixpkgs/blob/master/CONTRIBUTING.md , make sure your package is up to the standards e.g. add a suitable [https://nixos.org/manual/nixpkgs/stable/#sec-standard-meta-attributes <code>meta</code> section].
# Now that your package builds and runs, it's time to move it to nixpkgs. Read [https://github.com/NixOS/nixpkgs/blob/master/CONTRIBUTING.md nixpkgs/CONTRIBUTING.md], make sure your package is up to the standards e.g. add a suitable [https://nixos.org/manual/nixpkgs/stable/#sec-standard-meta-attributes <code>meta</code> section].
# Git clone https://github.com/NixOS/nixpkgs , figure out the best category / directory for the application (within https://github.com/NixOS/nixpkgs/tree/master/pkgs/ ), create the directory for your application, and move your default.nix there.
# Git clone https://github.com/NixOS/nixpkgs , figure out the best category / directory for the application (within https://github.com/NixOS/nixpkgs/tree/master/pkgs/ ), create the directory for your application, and move your default.nix there.
# If you used <code>with import <nixpkgs> {};</code> to iterate more quickly, now is the time to replace that with the actual dependencies as an attribute set at the beginning of the file e.g. <code>{ lib, stdenv, fetchFromGitHub }:</code>
# If you used <code>with import <nixpkgs> {};</code> to iterate more quickly, now is the time to replace that with the actual dependencies as an attribute set at the beginning of the file e.g. <code>{ lib, stdenv, fetchFromGitHub }:</code>
Line 401: Line 403:


* [[Generic Algorithm on Doing Packaging]]
* [[Generic Algorithm on Doing Packaging]]
* [https://nixos.org/guides/nix-pills/fundamentals-of-stdenv.html Fundamentals of Stdenv] in Nix Pills
* [https://nixos.org/guides/nix-pills/developing-with-nix-shell.html Developing with nix-shell] in Nix Pills


[[Category:Development]]
[[Category:Development]]