Jump to content

Python: Difference between revisions

From NixOS Wiki
Order matters in the case of multiple python3.withPackages
Drupol (talk | contribs)
m Add an example of using the new command line to spawn a shell with python and custom modules.
(46 intermediate revisions by 24 users not shown)
Line 1: Line 1:


== Installation ==
== Python development environments with Nix ==
Nix supports a number of approaches to creating "development environments" for Python programming. These provide functionality analogous to [https://virtualenv.pypa.io/en/latest/ virtualenv] or [https://docs.conda.io/en/latest/ conda]: a shell environment with access to pinned versions of the <code>python</code> executable and Python packages.


Python is a development package, and '''not meant to go in your system or home configuration'''.
=== Using the Nixpkgs Python infrastructure via <code>shell.nix</code> (recommended) ===
Nixpkgs has the few last Python versions packaged, as well as a consequent set of Python packages packaged that you can use to quickly create a Python environment.


If you need access to python for development, create a <code>shell.nix</code> for the specific project, along with any libraries needed:
Create a file <code>shell.nix</code> in the project directory, with the following template:


<syntaxHighlight lang="nix">
<syntaxhighlight lang="nix" line="1">
# shell.nix
let
let
   pkgs = import <nixpkgs> {};
  # We pin to a specific nixpkgs commit for reproducibility.
  # Last updated: 2024-04-29. Check for new commits at https://status.nixos.org.
   pkgs = import (fetchTarball "https://github.com/NixOS/nixpkgs/archive/cf8cc1201be8bc71b7cbbbdaf349b22f4f99c7ae.tar.gz") {};
in pkgs.mkShell {
in pkgs.mkShell {
   packages = [
   packages = [
     (pkgs.python3.withPackages (python-pkgs: [
     (pkgs.python3.withPackages (python-pkgs: with python-pkgs; [
       python-pkgs.pandas
       # select Python packages here
       python-pkgs.requests
      pandas
       requests
     ]))
     ]))
   ];
   ];
}
}
</syntaxHighlight>
</syntaxhighlight>


Then run <code>nix-shell</code> to use the shell.
In this example, we create a Python environment with packages <code>pandas</code> and <code>requests</code>.


== Using alternative packages ==
You can find Python packages that are available in Nixpkgs using [https://search.nixos.org/packages search.nixos.org]. For instance, type a Python package name like <code>numpy</code> in the search bar and click on the search button on the right. You can narrow down results by clicking on eg. "python311Packages" in the "Package sets" section on the left. Note that in the snippet above, on lines 8 and 9, each package is listed in the form <code>python-pkgs.<name></code> where <code><name></code> corresponds to the one found in [https://search.nixos.org/packages search.nixos.org] . See [https://nix.dev/tutorials/nix-language.html Nix language basics] for more information on the <code>python-pkgs</code> attribute set.


We saw above how to install Python packages using nixpkgs. Since these are written by hand by nixpkgs maintainers, it isn't uncommon for packages you want to be missing or out of date. To create a custom Python environment with your own package(s), first create a derivation for each python package (look at examples in the <code>python-modules</code> subfolder in Nixpkgs). Then, use those derivations with <code>callPackage</code> as follows:
Once you have picked the Python packages you want, run <code>nix-shell</code> (or <code>nix develop -f shell.nix</code>) to build the Python environment and enter it. Once in the environment Python will be available in your PATH, so you can run eg. <code>python --version</code>.


<syntaxhighlight lang="nix">
Note that with NixOS, this method can be used to install packages at the system level, e.g. <syntaxhighlight lang="nix">
with pkgs;
environment.systemPackages = with pkgs; [
let
   # ...
   my-python-package = ps: ps.callPackage ./my-package.nix {};
   (python3.withPackages (python-pkgs: with python-pkgs; [
   python-with-my-packages = python3.withPackages(ps: with ps; [
      pandas
    (my-python-package ps)
      requests
   ]);
   ]))
in ...
];
</syntaxhighlight>
</syntaxhighlight>


=== Package and development shell for a python project ===
=== Using Nix shell (new command line) ===
nix shell --impure --expr '(import <nixpkgs> {}).python3.withPackages (ps: with ps; [ swh-core swh-scanner ])'
If you don't use the channels any more, you can replace <code><nixpkgs></code> by an instance of the <code>NixOS/nixpkgs</code> repository using its absolute path.
 
==== Using a Python package not in Nixpkgs ====
Python packages in Nixpkgs are created and updated by Nixpkgs maintainers. Although the community invests a great effort to keep a complete and up-to-date package set, some packages you want may be missing, out of date, or broken. To use your own packages in a Nix environment, you may package it yourself.
 
The following is a high-level overview. For a complete explanation, see [https://nixos.org/manual/nixpkgs/unstable/#developing-with-python Developing with Python] in the Nixpkgs Manual.


It is possible to use <code>buildPythonApplication</code> to package python applications. As explained in the nixpkgs manual, it uses the widely used `setup.py` file in order to package properly the application. We now show how to package a simple python application: a basic flask web server.
Generally, you may create a file that looks like this:<syntaxhighlight lang="nix" line="1">
# toolz.nix
{
  lib,
  buildPythonPackage,
  fetchPypi,
  setuptools,
  wheel,
}:


First, we write the python code, say in a file <code>web_interface.py</code>. Here we create a basic flask web server;
buildPythonPackage rec {
<syntaxhighlight lang="python">
  pname = "toolz";
#!/usr/bin/env python
  version = "0.10.0";
 
  src = fetchPypi {
    inherit pname version;
    hash = "sha256-CP3V73yWSArRHBLUct4hrNMjWZlvaaUlkpm1QP66RWA=";
  };
 
  # do not run tests
  doCheck = false;


from flask import Flask
  # specific to buildPythonPackage, see its reference
app = Flask(__name__)
  pyproject = true;
  build-system = [
    setuptools
    wheel
  ];
}
</syntaxhighlight>Given the file above is named <code>toolz.nix</code> and is the same directory as the previous <code>shell.nix</code> , you can edit <code>shell.nix</code> to use the package <code>toolz</code> above like so: <syntaxhighlight lang="nix" line="1">
# shell.nix
let
  pkgs = import <nixpkgs> {};


@app.route('/')
  python = pkgs.python3.override {
def hello_world():
    self = python;
     return 'Hello, World!'
    packageOverrides = pyfinal: pyprev: {
      toolz = pyfinal.callPackage ./toolz.nix { };
     };
  };


if __name__ == '__main__':
in pkgs.mkShell {
     app.run(host="0.0.0.0", port=8080)
  packages = [
</syntaxhighlight>
     (python.withPackages (python-pkgs: [
      # select Python packages here
      python-pkgs.pandas
      python-pkgs.requests
      python-pkgs.toolz
    ]))
  ];
}
</syntaxhighlight>Next time you enter the shell specified by this file, Nix will build and include the Python package you have written.


Then, we create the <code>setup.py</code> file, which basically explains which are the executables:
=== Running Python packages which requires compilation and/or contains libraries precompiled without <code>nix</code> ===
<syntaxhighlight lang="python">
#!/usr/bin/env python


from setuptools import setup, find_packages
If you want to use some Python packages containing libraries precompiled without <code>nix</code> as for example <code>[https://pypi.org/project/grpcio/ grpcio]</code> or <code>[https://pypi.org/project/numpy Numpy]</code>, you may encounter the following error :<syntaxhighlight lang="shell-session">
$ python -c 'import grpc'
Traceback (most recent call last):
  File "<string>", line 1, in <module>
  File "/.../grpc/__init__.py", line 22, in <module>
    from grpc import _compression
  File "/.../grpc/_compression.py", line 20, in <module>
    from grpc._cython import cygrpc
ImportError: libstdc++.so.6: cannot open shared object file: No such file or directory


setup(name='demo-flask-vuejs-rest',
</syntaxhighlight>This means that the Python package depends on compiled dynamically linked binaries that your NixOs environment fail to resolve.
      version='1.0',
      # Modules to import from other scripts:
      packages=find_packages(),
      # Executables
      scripts=["web_interface.py"],
    )
</syntaxhighlight>


Finally, our nix derivation is now trivial: the file <code>derivation.nix</code> just needs to provide the python packages (here flask):
On NixOS, installing packages that need to compile code or use C libraries from outside of the <code>nix</code> package manager may fail if dependencies are not found in the expected locations. There are multiple ways to solve this, and most of them are just different ways for adding <code>/nix/store/...</code> to <code>$LD_LIBRARY_PATH</code>.
<syntaxhighlight lang="nix">
{ lib, python3Packages }:
with python3Packages;
buildPythonApplication {
  pname = "demo-flask-vuejs-rest";
  version = "1.0";


  propagatedBuildInputs = [ flask ];
After doing one of the following, you should be able to install compiled libraries using <code>venv</code>, <code>poetry</code>, <code>uv</code>, <code>conda</code> or other packages managers.


   src = ./.;
==== Using nix overlay ====
<syntaxhighlight lang="nix">
{
   nixpkgs.overlays = [(
    self: super: rec {
      # https://github.com/NixOS/nixpkgs/blob/c339c066b893e5683830ba870b1ccd3bbea88ece/nixos/modules/programs/nix-ld.nix#L44
      # > We currently take all libraries from systemd and nix as the default.
      pythonldlibpath = lib.makeLibraryPath (with super; [
        zlib zstd stdenv.cc.cc curl openssl attr libssh bzip2 libxml2 acl libsodium util-linux xz systemd
      ]);
      # here we are overriding python program to add LD_LIBRARY_PATH to it's env
      python = super.stdenv.mkDerivation {
        name = "python";
        buildInputs = [ super.makeWrapper ];
        src = super.python311;
        installPhase = ''
          mkdir -p $out/bin
          cp -r $src/* $out/
          wrapProgram $out/bin/python3 --set LD_LIBRARY_PATH ${pythonldlibpath}
          wrapProgram $out/bin/python3.11 --set LD_LIBRARY_PATH ${pythonldlibpath}
        '';
      };
      poetry = super.stdenv.mkDerivation {
        name = "poetry";
        buildInputs = [ super.makeWrapper ];
        src = super.poetry;
        installPhase = ''
          mkdir -p $out/bin
          cp -r $src/* $out/
          wrapProgram $out/bin/poetry --set LD_LIBRARY_PATH ${pythonldlibpath}
        '';
      };
    }
  )];
  environment.systemPackages = with pkgs; [
    python  # here python will be taken from the overlay up here
    poetry
  ];
}
}
</syntaxhighlight>
</syntaxhighlight>


and we can now load this derivation from our file <code>default.nix</code>:
==== Using [https://github.com/Mic92/nix-ld nix-ld] ====
 
<syntaxhighlight lang="nix">
<syntaxhighlight lang="nix">
{ pkgs ? import <nixpkgs> {} }:
{
pkgs.callPackage ./derivation.nix {}
  programs.nix-ld = {
    enable = true;
    libraries = with pkgs; [
      zlib zstd stdenv.cc.cc curl openssl attr libssh bzip2 libxml2 acl libsodium util-linux xz systemd
    ];
  };
  # https://github.com/nix-community/nix-ld?tab=readme-ov-file#my-pythonnodejsrubyinterpreter-libraries-do-not-find-the-libraries-configured-by-nix-ld
  environment.systemPackages = [
    (pkgs.writeShellScriptBin "python" ''
      export LD_LIBRARY_PATH=$NIX_LD_LIBRARY_PATH
      exec ${pkgs.python3}/bin/python "$@"
    '')
  ];
  # another (dangerous) solution
  # environment.systemPackages = with pkgs; [ python3 ];
  # programs.bash = {
  #  enable = true;
  #  initExtra = ''
  #    export LD_LIBRARY_PATH=$LD_LIBRARY_PATH''${LD_LIBRARY_PATH:+:}$NIX_LD_LIBRARY_PATH
  #  '';
  # };
}
</syntaxhighlight>
</syntaxhighlight>


We can now build with:
==== Using [https://github.com/GuillaumeDesforges/fix-python/ fix-python] ====
<syntaxhighlight lang=console>
{{Note|fix-python will <strong>patch</strong> binary files in the virtual environment without following symlinks.}}
$ nix-build
 
[...]
Install with:
$ ./result/bin/web_interface.py
* Serving Flask app ".web_interface" (lazy loading)
[...]
</syntaxhighlight>
or just enter a nix-shell, and directly execute your program or python if it's easier to develop:
<syntaxhighlight lang=console>
$ nix-shell
[...]
[nix-shell]$ chmod +x web_interface.py
[nix-shell]$ ./web_interface.py
* Serving Flask app "web_interface" (lazy loading)
[...]


[nix-shell]$ python
<syntaxhighlight lang="shell">
Python 3.8.7 (default, Dec 21 2020, 17:18:55)
nix profile install github:GuillaumeDesforges/fix-python
[GCC 10.2.0] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import flask
>>>
</syntaxhighlight>
</syntaxhighlight>


=== Python virtual environment ===
Enter the venv and run:


Starting from Python 3 virtual environment is natively supported.
<syntaxhighlight lang="shell">
The Python 3 venv approach has the benefit of forcing you to choose a specific version of the Python 3 interpreter that should be used to create the virtual environment. This avoids any confusion as to which Python installation the new environment is based on.
fix-python --venv .venv
 
Recommended usage:
* Python 3.3-3.4 (old): the recommended way to create a virtual environment was to use the pyvenv command-line tool that also comes included with your Python 3 installation by default.
* Python 3.6+: <code>python3 -m venv</code> is the way to go.
 
Put your packages in a requirements.txt:
<syntaxhighlight lang=text>
pandas
requests
</syntaxhighlight>
</syntaxhighlight>


Then setup the virtualenv:
==== Using <code>buildFHSEnv</code> ====
<syntaxhighlight lang="shell">
<syntaxhighlight lang="nix">
python -m venv .venv
#!/usr/bin/env nix-shell
source .venv/bin/activate
{ pkgs ? import <nixpkgs> { } }:
pip install -r requirements.txt
(
  let base = pkgs.appimageTools.defaultFhsEnvArgs; in
  pkgs.buildFHSEnv (base // {
    name = "FHS";
    targetPkgs = pkgs: (with pkgs; [
      gcc glibc zlib
    ]);
    runScript = "zsh";
    extraOutputsToInstall = [ "dev" ];
  })
).env
</syntaxhighlight>
</syntaxhighlight>


Installing packages with <code>pip</code> that need to compile code or use C libraries will sometimes fail due to not finding dependencies in the expected places. In that case you can use <code>buildFHSUserEnv</code> to make yourself a sandbox that appears like a more typical Linux install (or you can also certainly use <code>nix-ld</code> to turn your whole system into a more standard Linux distribution). For example if you were working with machine learning code you could use:
==== Using a custom nix-shell ====


<syntaxhighlight lang="nix">
The following configuration automatically fix the dependencies:<syntaxhighlight lang="nixos" line="1">
{ pkgs ? import <nixpkgs> {} }:
let
(pkgs.buildFHSUserEnv {
  python = pkgs.python311;
   name = "pipzone";
   # We currently take all libraries from systemd and nix as the default
   targetPkgs = pkgs: (with pkgs; [
  # https://github.com/NixOS/nixpkgs/blob/c339c066b893e5683830ba870b1ccd3bbea88ece/nixos/modules/programs/nix-ld.nix#L44
     python39
   pythonldlibpath = lib.makeLibraryPath (with pkgs; [
    python39Packages.pip
     zlib zstd stdenv.cc.cc curl openssl attr libssh bzip2 libxml2 acl libsodium util-linux xz systemd
    python39Packages.virtualenv
    cudaPackages.cudatoolkit
   ]);
   ]);
   runScript = "bash";
   patchedpython = (python.overrideAttrs (
}).env
    previousAttrs: {
</syntaxhighlight>
      # Add the nix-ld libraries to the LD_LIBRARY_PATH.
      # creating a new library path from all desired libraries
      postInstall = previousAttrs.postInstall + ''
        mv  "$out/bin/python3.11" "$out/bin/unpatched_python3.11"
        cat << EOF >> "$out/bin/python3.11"
        #!/run/current-system/sw/bin/bash
        export LD_LIBRARY_PATH="${pythonldlibpath}"
        exec "$out/bin/unpatched_python3.11" "\$@"
        EOF
        chmod +x "$out/bin/python3.11"
      '';
    }
  ));
  # if you want poetry
  patchedpoetry =  ((pkgs.poetry.override { python3 = patchedpython; }).overrideAttrs (
    previousAttrs: {
      # same as above, but for poetry
      # not that if you dont keep the blank line bellow, it crashes :(
      postInstall = previousAttrs.postInstall + ''


In <code>pip-shell.nix</code>, and enter the environment with:
        mv "$out/bin/poetry" "$out/bin/unpatched_poetry"
        cat << EOF >> "$out/bin/poetry"
        #!/run/current-system/sw/bin/bash
        export LD_LIBRARY_PATH="${pythonldlibpath}"
        exec "$out/bin/unpatched_poetry" "\$@"
        EOF
        chmod +x "$out/bin/poetry"
      '';
    }
  ));
in
{
  environment.systemPackages = with pkgs; [
    patchedpython
    # if you want poetry
    patchedpoetry
  ];
}
</syntaxhighlight>This configuration set the <code>LD_LIBRARY_PATH</code> environment variable before running python using the <code>overrideAttrs</code><ref>https://nixos.org/manual/nixpkgs/stable/#sec-pkg-overrideAttrs</ref> function to override the <code>postInstall</code> script of cpython <code>mkDerivation</code><ref>https://github.com/NixOS/nixpkgs/blob/24.05/pkgs/development/interpreters/python/cpython/default.nix</ref>.


<syntaxhighlight lang="shell">
==== Prefix library paths using wrapProgram ====
nix-shell pip-shell.nix
wrapProgram is a part of the makeWrapper build input<ref>https://github.com/NixOS/nixpkgs/blob/master/pkgs/build-support/setup-hooks/make-wrapper.sh</ref>. By combining it with the symlinkJoin, we can create a wrapper around the Python executable that will always set the required library paths. It’s worth noting that, for this solution to be compatible with Darwin, we need to use a different wrap prefix, as shown in the example below.<syntaxhighlight lang="nixos" line="1">
virtualenv venv
let
source venv/bin/activate
  # We currently take all libraries from systemd and nix as the default
  # https://github.com/NixOS/nixpkgs/blob/c339c066b893e5683830ba870b1ccd3bbea88ece/nixos/modules/programs/nix-ld.nix#L44
  pythonldlibpath = lib.makeLibraryPath (with pkgs; [
    zlib zstd stdenv.cc.cc curl openssl attr libssh bzip2 libxml2 acl libsodium util-linux xz systemd
  ]);
  # Darwin requires a different library path prefix
  wrapPrefix = if (!pkgs.stdenv.isDarwin) then "LD_LIBRARY_PATH" else "DYLD_LIBRARY_PATH";
  patchedpython = (pkgs.symlinkJoin {
    name = "python";
    paths = [ pkgs.python312 ];
    buildInputs = [ pkgs.makeWrapper ];
    postBuild = ''
      wrapProgram "$out/bin/python3.12" --prefix ${wrapPrefix} : "${pythonldlibpath}"
    '';
  });
in
{
  environment.systemPackages = with pkgs; [
    patchedpython
  ];
}
</syntaxhighlight>
</syntaxhighlight>


==== Virtualenv without nix on NixOS ====
=== Using <code>venv</code> ===
Another option is to follow the [https://gist.github.com/GuillaumeDesforges/7d66cf0f63038724acf06f17331c9280 fix-python gist] to setup a virtualenv without explicitly entering a nix shell.


=== Emulating virtualenv with nix-shell ===
To create a Python virtual environment with <code>venv</code>:<syntaxhighlight lang="console">
In some cases virtualenv fails to install a library because it requires patching on NixOS (example 1, example 2, general issue). In this cases it is better to replace those libraries with ones from Nix.
$ nix-shell -p python3 --command "python -m venv .venv --copies"
</syntaxhighlight>You can then activate and use the Python virtual environment as usual and install dependencies with <code>pip</code> and similar.


Let's say, that nanomsg library fails to install in virtualenv. Then write a <code>shell.nix</code> file:
=== Using uv ===
<blockquote>A single tool to replace <code>pip</code>, <code>pip-tools</code>, <code>pipx</code>, <code>poetry</code>, <code>pyenv</code>, <code>virtualenv</code>, and more.</blockquote>uv is very simple to use. Simply <code>uv init</code> to get started. No need for shells, as it creates virtual environments.
 
As a systemPackage<syntaxhighlight lang="nix">
environment.systemPackages = with pkgs; [
    uv
];
</syntaxhighlight>or as a home-manager package<syntaxhighlight lang="nix">
home.packages = with pkgs; [
    uv
];
</syntaxhighlight>


=== Using poetry ===
<syntaxhighlight lang="nix">
<syntaxhighlight lang="nix">
# shell.nix
let
let
   pkgs = import <nixpkgs> {};
   pkgs = import <nixpkgs> {};
  nanomsg-py = ...build expression for this python library...;
in pkgs.mkShell {
in pkgs.mkShell {
   buildInputs = [
   packages = with pkgs; [
     pkgs.python3
     python310
     pkgs.python3.pkgs.requests
     (poetry.override { python3 = python310; })
    nanomsg-py
   ];
   ];
  shellHook = ''
    # Tells pip to put packages into $PIP_PREFIX instead of the usual locations.
    # See https://pip.pypa.io/en/stable/user_guide/#environment-variables.
    export PIP_PREFIX=$(pwd)/_build/pip_packages
    export PYTHONPATH="$PIP_PREFIX/${pkgs.python3.sitePackages}:$PYTHONPATH"
    export PATH="$PIP_PREFIX/bin:$PATH"
    unset SOURCE_DATE_EPOCH
  '';
}
}
</syntaxhighlight>
</syntaxhighlight>


After entering the environment with `nix-shell`, you can install new python libraries with dump `pip install`, but nanomsg will be detected as installed.
==== poetry2nix ====
[https://github.com/nix-community/poetry2nix poetry2nix] uses the contents of a <code>poetry.lock</code> and <code>pyproject.toml</code> file to create Nix derivations. It has several functions for generating development environments and python projects. Because some older python projects rely on deprecated build systems (see [https://github.com/nix-community/poetry2nix/blob/master/docs/edgecases.md edgecase.md] for more info), poetry2nix provides overrides so these packages can still be built.
=== Using micromamba ===


Discussion and consequences of this approach are in PR https://github.com/NixOS/nixpkgs/pull/55265.
Install the <code>micromamba</code> package to create environments and install packages as [https://github.com/mamba-org/mamba#micromamba documented by micromamba].
 
=== micromamba ===
 
Install the <code>micromamba</code> package.
You can create environments and install packages as [https://github.com/mamba-org/mamba#micromamba documented by micromamba] e.g.
<syntaxhighlight lang="shell">
micromamba create -n my-environment python=3.9 numpy=1.23.0 -c conda-forge
</syntaxhighlight>


To activate an environment you will need a [https://nixos.org/manual/nixpkgs/stable/#sec-fhs-environments FHS environment] e.g.:
To activate an environment you will need a [https://nixos.org/manual/nixpkgs/stable/#sec-fhs-environments FHS environment] e.g.:
<syntaxhighlight lang="console">
<syntaxhighlight lang="console">
$ nix-shell -E 'with import <nixpkgs> {}; (pkgs.buildFHSUserEnv { name = "fhs"; }).env'
$ nix-shell -E 'with import <nixpkgs> {}; (pkgs.buildFHSEnv { name = "fhs"; }).env'
$ eval "$(micromamba shell hook -s bash)"
$ eval "$(micromamba shell hook -s bash)"
$ micromamba activate my-environment
$ micromamba activate my-environment
Line 214: Line 352:
{ pkgs ? import <nixpkgs> {}}:
{ pkgs ? import <nixpkgs> {}}:
let
let
   fhs = pkgs.buildFHSUserEnv {
   fhs = pkgs.buildFHSEnv {
     name = "my-fhs-environment";
     name = "my-fhs-environment";


Line 225: Line 363:
       eval "$(micromamba shell hook --shell=posix)"
       eval "$(micromamba shell hook --shell=posix)"
       export MAMBA_ROOT_PREFIX=${builtins.getEnv "PWD"}/.mamba
       export MAMBA_ROOT_PREFIX=${builtins.getEnv "PWD"}/.mamba
       micromamba create -q -n my-mamba-environment
       if ! test -d $MAMBA_ROOT_PREFIX/envs/my-mamba-environment; then
          micromamba create --yes -q -n my-mamba-environment
      fi
       micromamba activate my-mamba-environment
       micromamba activate my-mamba-environment
       micromamba install --yes -f conda-requirements.txt -c conda-forge
       micromamba install --yes -f conda-requirements.txt -c conda-forge
Line 233: Line 373:
in fhs.env
in fhs.env
</syntaxhighlight>
</syntaxhighlight>
 
=== Using conda ===
 
=== conda ===


Install the package <code>conda</code> and run  
Install the package <code>conda</code> and run  
<syntaxhighlight lang="shell">
<syntaxhighlight lang="console">
conda-shell
$ conda-shell
conda-install
$ conda-install
conda env update --file environment.yml
$ conda env update --file environment.yml
</syntaxhighlight>
</syntaxhighlight>


==== Imperative use ====
==== Imperative use ====


It is also possible to use <code>conda-install</code> directly.
It is also possible to use <code>conda-install</code> directly. On first use, run:
On first use, run
<syntaxhighlight lang="console">
<syntaxhighlight lang="shell">
$ conda-shell
conda-shell
$ conda-install
conda-install
</syntaxhighlight>
</syntaxhighlight>
to set up conda in <code>~/.conda</code>
to set up conda in <code>~/.conda</code>


=== pip2nix ===
=== Using pixi ===
[https://github.com/nix-community/pip2nix pip2nix] generate nix expressions for Python packages.
Install the <code>pixi</code> package to create environments and install packages as [https://pixi.sh/latest/ documented by pixi]:<syntaxhighlight lang="console">
$ pixi init
$ pixi add python
</syntaxhighlight>To activate an environment you will need a [https://nixos.org/manual/nixpkgs/stable/#sec-fhs-environments FHS environment] e.g. a [https://github.com/NixOS/nixpkgs/issues/316443#issuecomment-2151963505 flake.nix] <ref>Suggested flake.nix by [https://github.com/jonas-w @jonas-w] in response to '''[https://github.com/NixOS/nixpkgs/issues/316443 #316443 <bdi>Unable to add / run packages with pixi</bdi>]'''</ref><syntaxhighlight lang="nixos">
{
  description = "pixi env";
  inputs = {
    flake-utils.url = "github:numtide/flake-utils";
  };
  outputs =
    { flake-utils, nixpkgs, ... }:
    flake-utils.lib.eachDefaultSystem (
      system:
      let
        pkgs = import nixpkgs { inherit system; };
        fhs = pkgs.buildFHSEnv {
          name = "pixi-env";
 
          targetPkgs = _: [ pkgs.pixi ];
        };
      in
      {
        devShell = fhs.env;
      }
    );
}
</syntaxhighlight>Then using  <code>[https://wiki.nixos.org/wiki/Development_environment_with_nix-shell#nix_develop nix develop]</code> the environment can be activated:<syntaxhighlight lang="console">
$ nix develop
$ pixi s
$ python
>>> import numpy as np
</syntaxhighlight>
 
==== Using Home Manager ====
Alternatively an [https://nixos.org/manual/nixpkgs/stable/#sec-fhs-environments FHS environment] can wrap pixi using [[Home Manager]] e.g<ref>Suggested home manager config by [https://github.com/jennydaman @jennydaman] in response to '''[https://github.com/NixOS/nixpkgs/issues/316443 #316443 <bdi>Unable to add / run packages with pixi</bdi>]'''</ref><syntaxhighlight lang="nixos">
{ lib, pkgs, ... }:
{
  home.packages = [
    (pkgs.buildFHSEnv {
      name = "pixi";
      runScript = "pixi";
      targetPkgs = pkgs: with pkgs; [ pixi ];
    })
  ];
}
</syntaxhighlight>Then the environment can be activated:<syntaxhighlight lang="console">
$ pixi s
$ python
>>> import numpy as np
</syntaxhighlight>
 
== Package a Python application ==
 
=== With <code>setup.py</code> ===
To package a Python application that uses <code>setup.py</code> you can use <code>buildPythonApplication</code>. More details about this and similar functions can be found in [https://nixos.org/manual/nixpkgs/stable/#building-packages-and-applications the nixpkgs manual].
 
For example, we can package this simple flask server <code>main.py:</code>
<syntaxhighlight lang="python">
#!/usr/bin/env python
 
from flask import Flask


Also see the [https://github.com/nix-community/pypi2nix pypi2nix]-project (abandoned in 2019).
app = Flask(__name__)


== Contribution guidelines ==
@app.route('/')
def hello_world():
    return 'Hello, World!'


=== Libraries ===
if __name__ == '__main__':
    app.run(host="0.0.0.0", port=8080)
</syntaxhighlight>


According to the [https://nixos.org/nixpkgs/manual/#contributing-guidelines official guidelines] for python new package expressions for libraries should be placed in <syntaxhighlight lang="bash" inline>pkgs/development/python-modules/<name>/default.nix</syntaxhighlight>. Those expressions are then referenced from <code>pkgs/top-level/python-packages.nix</code> like in this example:
We also need a <code>setup.py</code> file, like this:
<syntaxhighlight lang="python">
from setuptools import setup, find_packages


setup(name='myFlaskServer',
      version='1.0',
      # Modules to import from other scripts:
      packages=find_packages(),
      # Executables
      scripts=["main.py"],
    )
</syntaxhighlight>
Then, we use the <code>buildPythonApplication</code> in the <code>default.nix</code>:
<syntaxhighlight lang="nix">
<syntaxhighlight lang="nix">
{ pkgs ? import <nixpkgs> {} }:
pkgs.python3Packages.buildPythonApplication {
  pname = "myFlaskApp";
  version = "0.1.0";
  propagatedBuildInputs = with pkgs.python3Packages; [
    flask
  ];
  src = ./.;
}
</syntaxhighlight>Finally, build your project using <code>nix-build</code>. The result will be executable in <code>./result/bin/app.py</code>.
=== With <code>pyproject.toml</code> ===
When your project is using <code>pyproject.toml</code>you can use [https://github.com/nix-community/pyproject.nix pyproject.nix] to package your application.
First, a simple file structure could look like this:<syntaxhighlight>
├── app/
    └── main.py
├── flake.nix
├── pyproject.toml
└── README.md
</syntaxhighlight>To reuse the example from above, we use the same flask application:<syntaxhighlight lang="python">
from flask import Flask
app = Flask(__name__)
@app.route('/')
def hello_world():
    return 'Hello, World!'
if __name__ == '__main__':
    app.run(host="0.0.0.0", port=8080)
</syntaxhighlight>Also, you need to define the <code>pyproject.toml</code>. Here, we only show some of the important parts. Please refer to <code>pyproject.nix</code> [https://nix-community.github.io/pyproject.nix/use-cases/pyproject.html documentation] for a full example.<syntaxhighlight lang="toml">
[project]
name = "my-app"
version = "0.1.0"
description = "Simple app"
# define any Python dependencies
dependencies = [
  "flask>3",
]
# define the CLI executable
# Here, we define the entry point to be the 'main()' function in the module 'app/main.py'
[project.scripts]
cli = "app.main:main"
</syntaxhighlight>We package the application by calling the <code>loadPyproject</code> function from <code>pyproject.nix</code>. Again, we only show a minimal example. More information can be found in the [https://nix-community.github.io/pyproject.nix/use-cases/pyproject.html documentation]. Note that this example relies on flakes in contrast to some of the others on this page.<syntaxhighlight lang="nix">
{
{
   aenum = callPackage ../development/python-modules/aenum { };
   description = "A basic flake using pyproject.toml project metadata";
 
  inputs = {
    pyproject-nix = {
      url = "github:nix-community/pyproject.nix";
      inputs.nixpkgs.follows = "nixpkgs";
    };
  };
 
  outputs = { nixpkgs, pyproject-nix, ... }:
    let
      inherit (nixpkgs) lib;
 
      project = pyproject-nix.lib.project.loadPyproject {
        # Read & unmarshal pyproject.toml relative to this project root.
        # projectRoot is also used to set `src` for renderers such as buildPythonPackage.
        projectRoot = ./.;
      };
 
      # This example is only using x86_64-linux
      pkgs = nixpkgs.legacyPackages.x86_64-linux;
 
      python = pkgs.python3;
 
    in
    {
      # Build our package using `buildPythonPackage
      packages.x86_64-linux.default =
        let
          # Returns an attribute set that can be passed to `buildPythonPackage`.
          attrs = project.renderers.buildPythonPackage { inherit python; };
        in
        # Pass attributes to buildPythonPackage.
        # Here is a good spot to add on any missing or custom attributes.
        python.pkgs.buildPythonPackage (attrs // {
          env.CUSTOM_ENVVAR = "hello";
        });
    };
}
}
</syntaxhighlight>To run the application, call <code>nix run</code>.
You can also launch an IDE under <code>nix develop</code> and get full dependency resolution. For example, the following command opens VS Code in the constructed environment:
<syntaxhighlight lang="shell-session">
$ nix develop --command code
</syntaxhighlight>
</syntaxhighlight>


The reasoning behind this is the large size of <code>pkgs/top-level/python-packages.nix</code>.
== Nixpkgs Python contribution guidelines ==


=== Applications ===
=== Libraries ===


Python applications instead should be referenced directly from <code>pkgs/top-level/all-packages.nix</code>.
According to the [https://nixos.org/nixpkgs/manual/#contributing-guidelines official guidelines] for Python, new package expressions for libraries should be placed in <syntaxhighlight lang="bash" inline>pkgs/development/python-modules/<name>/default.nix</syntaxhighlight>.


The expression should take <code>pythonPackages</code> as one of the arguments, which guarantees that packages belong to the same set. For example:
Those expressions are then referenced from <code>pkgs/top-level/python-packages.nix</code> as in


<syntaxhighlight lang="nix">
<syntaxhighlight lang="nix">
{ lib
  aenum = callPackage ../development/python-modules/aenum { };
, pythonPackages
</syntaxhighlight>
}:
 
=== Applications ===
 
Applications meant to be executed should be referenced directly from <code>pkgs/top-level/all-packages.nix</code>.


with pythonPackages;
Other Python packages used in the Python package of the application should be taken from the <code>callPackage</code> argument <code>pythonPackages</code> , which guarantees that they belong to the same "pythonPackage" set. For example:


buildPythonApplication rec {
<syntaxhighlight lang="nix" line="1">
# ...
{
  lib,
  pythonPackages,
}:
buildPythonApplication {
  propagatedBuildInputs = [ pythonPackages.numpy ];
  # ...
}
</syntaxhighlight>
</syntaxhighlight>
== Special Modules ==
== Special Modules ==
Line 313: Line 632:


== Performance ==
== Performance ==
The derivation of cPython that is available via <code>nixpkgs</code> does not contain optimizations enabled, specifically Profile Guided Optimization (PGO) and Link Time Optimization (LTO). See [https://docs.python.org/3/using/configure.html#performance-options Configuring Python 3.1.3. Performance options]  
The derivation of CPython that is available via <code>nixpkgs</code> only contains optimizations that do not harm reproducibility. Link-Time-Optimization (LTO) is only enabled on 64-bit Linux systems, while Profile Guided Optimization (PGO) is currently disabled. See [https://docs.python.org/3/using/configure.html#performance-options Configuring Python 3.1.3. Performance options]  
Additionally, when you compile something within <code>nix-shell</code> or a derivation; by default there are security hardening flags passed to the compiler which do have a small performance impact.
Additionally, when compiling something within <code>nix-shell</code> or a derivation security hardening flags are passed to the compiler by default which may have a small performance impact.
 
As of the time of this writing; these optimizations cause Python builds to be non-reproducible and increase install times for the derivation. For a more detailed overview of the trials and tabulations of discovering the performance regression; see [https://discourse.nixos.org/t/why-is-the-nix-compiled-python-slower/18717 Why is the nix-compiled Python slower?] thread on the nix forums.
 


At the time of writing certain optimizations cause Python wheels to be non-reproducible and increase install times. For a detailed overview of the trials and tribulations of discovering such performance regressions see [https://discourse.nixos.org/t/why-is-the-nix-compiled-python-slower/18717 Why is the nix-compiled Python slower?].
=== Regression ===
=== Regression ===
With the <code>nixpkgs</code> version of Python you can expect anywhere from a 30-40% regression on synthetic benchmarks. For example:  
With the <code>nixpkgs</code> version of Python you can expect anywhere from a 30-40% regression on synthetic benchmarks. For example:  
Line 330: Line 647:
</syntaxhighlight>
</syntaxhighlight>


However, synthetic benchmarks are not a reflection of a real-world use case. In most situations, the performance difference between optimized & non-optimized interpreters is minimal. For example; using <code>pylint</code> with a significant number of custom linters to go scan a very large Python codebase (>6000 files) resulted in only a 5.5% difference, instead of 40%. Other workflows that were not performance sensitive saw no impact to their run times.
However, synthetic benchmarks are not necessarily reflective of real-world performance. In common real-world situations, the performance difference between optimized and non-optimized interpreters is minimal. For example, using <code>pylint</code> with a significant number of custom linters to scan a very large Python codebase (>6000 files) resulted in only a 5.5% difference. Other workflows that were not performance sensitive saw no impact to their run times.
 
 
=== Possible Optimizations ===
=== Possible Optimizations ===
If you run code that heavily depends on Python performance (data science, machine learning), and you want to have the most performant Python interpreter possible, here are some possible things you can do:
If you run code that heavily depends on Python performance, and you desire the most performant Python interpreter possible, here are some possible things you can do:


* Enable the <code>enableOptimizations</code> flag for your Python derivation. [https://discourse.nixos.org/t/why-is-the-nix-compiled-python-slower/18717/10 Example] Do note that this will cause you to compile Python the first time that you run it; which will take a few minutes.
* '''Enable the <code>enableOptimizations</code> flag for your Python derivation'''. See [https://discourse.nixos.org/t/why-is-the-nix-compiled-python-slower/18717/10 Example]. Do note that this will cause you to compile Python the first time that you run it which will take a few minutes.
* Switch to a newer version of Python. In the example above, going from 3.8 to 3.10 yielded an average 7.5% performance improvement; but this is only a single benchmark. Switching versions most likely won't make all your code 7.5% faster.
* '''Switch to a newer version of Python'''. In the example above, going from 3.8 to 3.10 yielded an average 7.5% performance improvement, but this is only a single benchmark. Switching versions most likely won't make all your code 7.5% faster.
* Disable hardening, although this only yields a small performance boost; and it has impacts beyond Python code. [https://nixos.org/manual/nixpkgs/stable/#sec-hardening-in-nixpkgs Hardening in Nixpkgs]
* '''Disable hardening'''. Beware this only yields a small performance boost and it has impacts beyond Python code. See [https://nixos.org/manual/nixpkgs/stable/#sec-hardening-in-nixpkgs Hardening in Nixpkgs].


'''Ultimately, it is up to your use case to determine if you need an optimized version of the Python interpreter. We encourage you to benchmark and test your code to determine if this is something that would benefit you.'''
'''Ultimately, it is up to your use case to determine if you need an optimized version of the Python interpreter. We encourage you to benchmark and test your code to determine if this is something that would benefit you.'''
Line 355: Line 670:
== See also ==
== See also ==


* [[Packaging/Python]]
* [https://nixos.org/manual/nixpkgs/unstable/#python "Python" in Nixpkgs Manual]
* [https://ryantm.github.io/nixpkgs/languages-frameworks/python/#python Python user guide in nixpkgs manual]
* [https://github.com/cachix/nixpkgs-python Nixpgs-python: A repo providing every version of python as flake ]
[[Category:Languages]]
[[Category:Languages]]
[[Category:Python]]

Revision as of 13:31, 26 March 2025

Python development environments with Nix

Nix supports a number of approaches to creating "development environments" for Python programming. These provide functionality analogous to virtualenv or conda: a shell environment with access to pinned versions of the python executable and Python packages.

Using the Nixpkgs Python infrastructure via shell.nix (recommended)

Nixpkgs has the few last Python versions packaged, as well as a consequent set of Python packages packaged that you can use to quickly create a Python environment.

Create a file shell.nix in the project directory, with the following template:

# shell.nix
let
  # We pin to a specific nixpkgs commit for reproducibility.
  # Last updated: 2024-04-29. Check for new commits at https://status.nixos.org.
  pkgs = import (fetchTarball "https://github.com/NixOS/nixpkgs/archive/cf8cc1201be8bc71b7cbbbdaf349b22f4f99c7ae.tar.gz") {};
in pkgs.mkShell {
  packages = [
    (pkgs.python3.withPackages (python-pkgs: with python-pkgs; [
      # select Python packages here
      pandas
      requests
    ]))
  ];
}

In this example, we create a Python environment with packages pandas and requests.

You can find Python packages that are available in Nixpkgs using search.nixos.org. For instance, type a Python package name like numpy in the search bar and click on the search button on the right. You can narrow down results by clicking on eg. "python311Packages" in the "Package sets" section on the left. Note that in the snippet above, on lines 8 and 9, each package is listed in the form python-pkgs.<name> where <name> corresponds to the one found in search.nixos.org . See Nix language basics for more information on the python-pkgs attribute set.

Once you have picked the Python packages you want, run nix-shell (or nix develop -f shell.nix) to build the Python environment and enter it. Once in the environment Python will be available in your PATH, so you can run eg. python --version.

Note that with NixOS, this method can be used to install packages at the system level, e.g.

environment.systemPackages = with pkgs; [
  # ...
  (python3.withPackages (python-pkgs: with python-pkgs; [
      pandas
      requests
  ]))
];

Using Nix shell (new command line)

nix shell --impure --expr '(import <nixpkgs> {}).python3.withPackages (ps: with ps; [ swh-core swh-scanner ])'

If you don't use the channels any more, you can replace <nixpkgs> by an instance of the NixOS/nixpkgs repository using its absolute path.

Using a Python package not in Nixpkgs

Python packages in Nixpkgs are created and updated by Nixpkgs maintainers. Although the community invests a great effort to keep a complete and up-to-date package set, some packages you want may be missing, out of date, or broken. To use your own packages in a Nix environment, you may package it yourself.

The following is a high-level overview. For a complete explanation, see Developing with Python in the Nixpkgs Manual.

Generally, you may create a file that looks like this:

# toolz.nix
{
  lib,
  buildPythonPackage,
  fetchPypi,
  setuptools,
  wheel,
}:

buildPythonPackage rec {
  pname = "toolz";
  version = "0.10.0";

  src = fetchPypi {
    inherit pname version;
    hash = "sha256-CP3V73yWSArRHBLUct4hrNMjWZlvaaUlkpm1QP66RWA=";
  };

  # do not run tests
  doCheck = false;

  # specific to buildPythonPackage, see its reference
  pyproject = true;
  build-system = [
    setuptools
    wheel
  ];
}

Given the file above is named toolz.nix and is the same directory as the previous shell.nix , you can edit shell.nix to use the package toolz above like so:

# shell.nix
let
  pkgs = import <nixpkgs> {};

  python = pkgs.python3.override {
    self = python;
    packageOverrides = pyfinal: pyprev: {
      toolz = pyfinal.callPackage ./toolz.nix { };
    };
  };

in pkgs.mkShell {
  packages = [
    (python.withPackages (python-pkgs: [
      # select Python packages here
      python-pkgs.pandas
      python-pkgs.requests
      python-pkgs.toolz
    ]))
  ];
}

Next time you enter the shell specified by this file, Nix will build and include the Python package you have written.

Running Python packages which requires compilation and/or contains libraries precompiled without nix

If you want to use some Python packages containing libraries precompiled without nix as for example grpcio or Numpy, you may encounter the following error :

$ python -c 'import grpc'
Traceback (most recent call last):
  File "<string>", line 1, in <module>
  File "/.../grpc/__init__.py", line 22, in <module>
    from grpc import _compression
  File "/.../grpc/_compression.py", line 20, in <module>
    from grpc._cython import cygrpc
ImportError: libstdc++.so.6: cannot open shared object file: No such file or directory

This means that the Python package depends on compiled dynamically linked binaries that your NixOs environment fail to resolve.

On NixOS, installing packages that need to compile code or use C libraries from outside of the nix package manager may fail if dependencies are not found in the expected locations. There are multiple ways to solve this, and most of them are just different ways for adding /nix/store/... to $LD_LIBRARY_PATH.

After doing one of the following, you should be able to install compiled libraries using venv, poetry, uv, conda or other packages managers.

Using nix overlay

{
  nixpkgs.overlays = [(
    self: super: rec {
      # https://github.com/NixOS/nixpkgs/blob/c339c066b893e5683830ba870b1ccd3bbea88ece/nixos/modules/programs/nix-ld.nix#L44
      # > We currently take all libraries from systemd and nix as the default.
      pythonldlibpath = lib.makeLibraryPath (with super; [
        zlib zstd stdenv.cc.cc curl openssl attr libssh bzip2 libxml2 acl libsodium util-linux xz systemd
      ]);
      # here we are overriding python program to add LD_LIBRARY_PATH to it's env
      python = super.stdenv.mkDerivation {
        name = "python";
        buildInputs = [ super.makeWrapper ];
        src = super.python311;
        installPhase = ''
          mkdir -p $out/bin
          cp -r $src/* $out/
          wrapProgram $out/bin/python3 --set LD_LIBRARY_PATH ${pythonldlibpath}
          wrapProgram $out/bin/python3.11 --set LD_LIBRARY_PATH ${pythonldlibpath}
        '';
      };
      poetry = super.stdenv.mkDerivation {
        name = "poetry";
        buildInputs = [ super.makeWrapper ];
        src = super.poetry;
        installPhase = ''
          mkdir -p $out/bin
          cp -r $src/* $out/
          wrapProgram $out/bin/poetry --set LD_LIBRARY_PATH ${pythonldlibpath}
        '';
      };
    }
  )];
  environment.systemPackages = with pkgs; [
    python  # here python will be taken from the overlay up here
    poetry
  ];
}

Using nix-ld

{
  programs.nix-ld = {
    enable = true;
    libraries = with pkgs; [
      zlib zstd stdenv.cc.cc curl openssl attr libssh bzip2 libxml2 acl libsodium util-linux xz systemd
    ];
  };
  # https://github.com/nix-community/nix-ld?tab=readme-ov-file#my-pythonnodejsrubyinterpreter-libraries-do-not-find-the-libraries-configured-by-nix-ld
  environment.systemPackages = [
    (pkgs.writeShellScriptBin "python" ''
      export LD_LIBRARY_PATH=$NIX_LD_LIBRARY_PATH
      exec ${pkgs.python3}/bin/python "$@"
    '')
  ];
  # another (dangerous) solution
  # environment.systemPackages = with pkgs; [ python3 ];
  # programs.bash = {
  #   enable = true;
  #   initExtra = ''
  #     export LD_LIBRARY_PATH=$LD_LIBRARY_PATH''${LD_LIBRARY_PATH:+:}$NIX_LD_LIBRARY_PATH
  #   '';
  # };
}

Using fix-python

Note: fix-python will patch binary files in the virtual environment without following symlinks.

Install with:

nix profile install github:GuillaumeDesforges/fix-python

Enter the venv and run:

fix-python --venv .venv

Using buildFHSEnv

#!/usr/bin/env nix-shell
{ pkgs ? import <nixpkgs> { } }:
(
  let base = pkgs.appimageTools.defaultFhsEnvArgs; in
  pkgs.buildFHSEnv (base // {
    name = "FHS";
    targetPkgs = pkgs: (with pkgs; [
      gcc glibc zlib
    ]);
    runScript = "zsh";
    extraOutputsToInstall = [ "dev" ];
  })
).env

Using a custom nix-shell

The following configuration automatically fix the dependencies:

let
  python = pkgs.python311;
  # We currently take all libraries from systemd and nix as the default
  # https://github.com/NixOS/nixpkgs/blob/c339c066b893e5683830ba870b1ccd3bbea88ece/nixos/modules/programs/nix-ld.nix#L44
  pythonldlibpath = lib.makeLibraryPath (with pkgs; [
    zlib zstd stdenv.cc.cc curl openssl attr libssh bzip2 libxml2 acl libsodium util-linux xz systemd
  ]);
  patchedpython = (python.overrideAttrs (
    previousAttrs: {
      # Add the nix-ld libraries to the LD_LIBRARY_PATH.
      # creating a new library path from all desired libraries
      postInstall = previousAttrs.postInstall + ''
        mv  "$out/bin/python3.11" "$out/bin/unpatched_python3.11"
        cat << EOF >> "$out/bin/python3.11"
        #!/run/current-system/sw/bin/bash
        export LD_LIBRARY_PATH="${pythonldlibpath}"
        exec "$out/bin/unpatched_python3.11" "\$@"
        EOF
        chmod +x "$out/bin/python3.11"
      '';
    }
  ));
  # if you want poetry
  patchedpoetry =  ((pkgs.poetry.override { python3 = patchedpython; }).overrideAttrs (
    previousAttrs: {
      # same as above, but for poetry
      # not that if you dont keep the blank line bellow, it crashes :(
      postInstall = previousAttrs.postInstall + ''

        mv "$out/bin/poetry" "$out/bin/unpatched_poetry"
        cat << EOF >> "$out/bin/poetry"
        #!/run/current-system/sw/bin/bash
        export LD_LIBRARY_PATH="${pythonldlibpath}"
        exec "$out/bin/unpatched_poetry" "\$@"
        EOF
        chmod +x "$out/bin/poetry"
      '';
    }
  ));
in
{
  environment.systemPackages = with pkgs; [
    patchedpython
    # if you want poetry
    patchedpoetry
  ];
}

This configuration set the LD_LIBRARY_PATH environment variable before running python using the overrideAttrs[1] function to override the postInstall script of cpython mkDerivation[2].

Prefix library paths using wrapProgram

wrapProgram is a part of the makeWrapper build input[3]. By combining it with the symlinkJoin, we can create a wrapper around the Python executable that will always set the required library paths. It’s worth noting that, for this solution to be compatible with Darwin, we need to use a different wrap prefix, as shown in the example below.

let
  # We currently take all libraries from systemd and nix as the default
  # https://github.com/NixOS/nixpkgs/blob/c339c066b893e5683830ba870b1ccd3bbea88ece/nixos/modules/programs/nix-ld.nix#L44
  pythonldlibpath = lib.makeLibraryPath (with pkgs; [
    zlib zstd stdenv.cc.cc curl openssl attr libssh bzip2 libxml2 acl libsodium util-linux xz systemd
  ]);
  # Darwin requires a different library path prefix
  wrapPrefix = if (!pkgs.stdenv.isDarwin) then "LD_LIBRARY_PATH" else "DYLD_LIBRARY_PATH";
  patchedpython = (pkgs.symlinkJoin {
    name = "python";
    paths = [ pkgs.python312 ];
    buildInputs = [ pkgs.makeWrapper ];
    postBuild = ''
      wrapProgram "$out/bin/python3.12" --prefix ${wrapPrefix} : "${pythonldlibpath}"
    '';
  });
in
{
  environment.systemPackages = with pkgs; [
    patchedpython
  ];
}

Using venv

To create a Python virtual environment with venv:

$ nix-shell -p python3 --command "python -m venv .venv --copies"

You can then activate and use the Python virtual environment as usual and install dependencies with pip and similar.

Using uv

A single tool to replace pip, pip-tools, pipx, poetry, pyenv, virtualenv, and more.

uv is very simple to use. Simply uv init to get started. No need for shells, as it creates virtual environments. As a systemPackage

environment.systemPackages = with pkgs; [
    uv
];

or as a home-manager package

home.packages = with pkgs; [
    uv
];

Using poetry

# shell.nix
let
  pkgs = import <nixpkgs> {};
in pkgs.mkShell {
  packages = with pkgs; [
    python310
    (poetry.override { python3 = python310; })
  ];
}

poetry2nix

poetry2nix uses the contents of a poetry.lock and pyproject.toml file to create Nix derivations. It has several functions for generating development environments and python projects. Because some older python projects rely on deprecated build systems (see edgecase.md for more info), poetry2nix provides overrides so these packages can still be built.

Using micromamba

Install the micromamba package to create environments and install packages as documented by micromamba.

To activate an environment you will need a FHS environment e.g.:

$ nix-shell -E 'with import <nixpkgs> {}; (pkgs.buildFHSEnv { name = "fhs"; }).env'
$ eval "$(micromamba shell hook -s bash)"
$ micromamba activate my-environment
$ python
>>> import numpy as np

Eventually you'll probably want to put this in a shell.nix so you won't have to type all that stuff every time e.g.:

{ pkgs ? import <nixpkgs> {}}:
let
  fhs = pkgs.buildFHSEnv {
    name = "my-fhs-environment";

    targetPkgs = _: [
      pkgs.micromamba
    ];

    profile = ''
      set -e
      eval "$(micromamba shell hook --shell=posix)"
      export MAMBA_ROOT_PREFIX=${builtins.getEnv "PWD"}/.mamba
      if ! test -d $MAMBA_ROOT_PREFIX/envs/my-mamba-environment; then
          micromamba create --yes -q -n my-mamba-environment
      fi
      micromamba activate my-mamba-environment
      micromamba install --yes -f conda-requirements.txt -c conda-forge
      set +e
    '';
  };
in fhs.env

Using conda

Install the package conda and run

$ conda-shell
$ conda-install
$ conda env update --file environment.yml

Imperative use

It is also possible to use conda-install directly. On first use, run:

$ conda-shell
$ conda-install

to set up conda in ~/.conda

Using pixi

Install the pixi package to create environments and install packages as documented by pixi:

$ pixi init
$ pixi add python

To activate an environment you will need a FHS environment e.g. a flake.nix [4]

{
  description = "pixi env";
  inputs = {
    flake-utils.url = "github:numtide/flake-utils";
  };
  outputs =
    { flake-utils, nixpkgs, ... }:
    flake-utils.lib.eachDefaultSystem (
      system:
      let
        pkgs = import nixpkgs { inherit system; };
        fhs = pkgs.buildFHSEnv {
          name = "pixi-env";

          targetPkgs = _: [ pkgs.pixi ];
        };
      in
      {
        devShell = fhs.env;
      }
    );
}

Then using nix develop the environment can be activated:

$ nix develop
$ pixi s
$ python
>>> import numpy as np

Using Home Manager

Alternatively an FHS environment can wrap pixi using Home Manager e.g[5]

{ lib, pkgs, ... }:
{
  home.packages = [
    (pkgs.buildFHSEnv {
      name = "pixi";
      runScript = "pixi";
      targetPkgs = pkgs: with pkgs; [ pixi ];
    })
  ];
}

Then the environment can be activated:

$ pixi s
$ python
>>> import numpy as np

Package a Python application

With setup.py

To package a Python application that uses setup.py you can use buildPythonApplication. More details about this and similar functions can be found in the nixpkgs manual.

For example, we can package this simple flask server main.py:

#!/usr/bin/env python

from flask import Flask

app = Flask(__name__)

@app.route('/')
def hello_world():
    return 'Hello, World!'

if __name__ == '__main__':
    app.run(host="0.0.0.0", port=8080)

We also need a setup.py file, like this:

from setuptools import setup, find_packages

setup(name='myFlaskServer',
      version='1.0',
      # Modules to import from other scripts:
      packages=find_packages(),
      # Executables
      scripts=["main.py"],
     )

Then, we use the buildPythonApplication in the default.nix:

{ pkgs ? import <nixpkgs> {} }:

pkgs.python3Packages.buildPythonApplication {
  pname = "myFlaskApp";
  version = "0.1.0";

  propagatedBuildInputs = with pkgs.python3Packages; [
    flask
  ];

  src = ./.;
}

Finally, build your project using nix-build. The result will be executable in ./result/bin/app.py.

With pyproject.toml

When your project is using pyproject.tomlyou can use pyproject.nix to package your application.

First, a simple file structure could look like this:

├── app/
    └── main.py
├── flake.nix
├── pyproject.toml
└── README.md

To reuse the example from above, we use the same flask application:

from flask import Flask

app = Flask(__name__)

@app.route('/')
def hello_world():
    return 'Hello, World!'

if __name__ == '__main__':
    app.run(host="0.0.0.0", port=8080)

Also, you need to define the pyproject.toml. Here, we only show some of the important parts. Please refer to pyproject.nix documentation for a full example.

[project]
name = "my-app"
version = "0.1.0"
description = "Simple app"

# define any Python dependencies
dependencies = [
  "flask>3",
]

# define the CLI executable
# Here, we define the entry point to be the 'main()' function in the module 'app/main.py'
[project.scripts]
cli = "app.main:main"

We package the application by calling the loadPyproject function from pyproject.nix. Again, we only show a minimal example. More information can be found in the documentation. Note that this example relies on flakes in contrast to some of the others on this page.

{
  description = "A basic flake using pyproject.toml project metadata";

  inputs = {
    pyproject-nix = {
      url = "github:nix-community/pyproject.nix";
      inputs.nixpkgs.follows = "nixpkgs";
    };
  };

  outputs = { nixpkgs, pyproject-nix, ... }:
    let
      inherit (nixpkgs) lib;

      project = pyproject-nix.lib.project.loadPyproject {
        # Read & unmarshal pyproject.toml relative to this project root.
        # projectRoot is also used to set `src` for renderers such as buildPythonPackage.
        projectRoot = ./.;
      };

      # This example is only using x86_64-linux
      pkgs = nixpkgs.legacyPackages.x86_64-linux;

      python = pkgs.python3;

    in
    {
      # Build our package using `buildPythonPackage
      packages.x86_64-linux.default =
        let
          # Returns an attribute set that can be passed to `buildPythonPackage`.
          attrs = project.renderers.buildPythonPackage { inherit python; };
        in
        # Pass attributes to buildPythonPackage.
        # Here is a good spot to add on any missing or custom attributes.
        python.pkgs.buildPythonPackage (attrs // {
          env.CUSTOM_ENVVAR = "hello";
        });
    };
}

To run the application, call nix run.

You can also launch an IDE under nix develop and get full dependency resolution. For example, the following command opens VS Code in the constructed environment:

$ nix develop --command code

Nixpkgs Python contribution guidelines

Libraries

According to the official guidelines for Python, new package expressions for libraries should be placed in pkgs/development/python-modules/<name>/default.nix.

Those expressions are then referenced from pkgs/top-level/python-packages.nix as in

  aenum = callPackage ../development/python-modules/aenum { };

Applications

Applications meant to be executed should be referenced directly from pkgs/top-level/all-packages.nix.

Other Python packages used in the Python package of the application should be taken from the callPackage argument pythonPackages , which guarantees that they belong to the same "pythonPackage" set. For example:

{
  lib,
  pythonPackages,
}:
buildPythonApplication {
  propagatedBuildInputs = [ pythonPackages.numpy ];
  # ...
}

Special Modules

GNOME

gobject-introspection based python modules need some environment variables to work correctly. For standalone applications, wrapGAppsHook (see the relevant documentation) wraps the executable with the necessary variables. But this is not fit for development. In this case use a nix-shell with gobject-introspection and all the libraries you are using (gtk and so on) as buildInputs. For example:

$ nix-shell -p gobjectIntrospection gtk3 'python2.withPackages (ps: with ps; [ pygobject3 ])' --run "python -c \"import pygtkcompat; pygtkcompat.enable_gtk(version='3.0')\""

Or, if you want to use matplotlib interactively:

$ nix-shell -p gobject-introspection gtk3 'python36.withPackages(ps : with ps; [ matplotlib pygobject3 ipython ])'
$ ipython
In [1]: import matplotlib
In [2]: matplotlib.use('gtk3agg')
In [3]: import matplotlib.pyplot as plt
In [4]: plt.ion()
In [5]: plt.plot([1,3,2,4])

You can also set backend : GTK3Agg in your ~/.config/matplotlib/matplotlibrc file to avoid having to call matplotlib.use('gtk3agg').

Performance

The derivation of CPython that is available via nixpkgs only contains optimizations that do not harm reproducibility. Link-Time-Optimization (LTO) is only enabled on 64-bit Linux systems, while Profile Guided Optimization (PGO) is currently disabled. See Configuring Python 3.1.3. Performance options Additionally, when compiling something within nix-shell or a derivation security hardening flags are passed to the compiler by default which may have a small performance impact.

At the time of writing certain optimizations cause Python wheels to be non-reproducible and increase install times. For a detailed overview of the trials and tribulations of discovering such performance regressions see Why is the nix-compiled Python slower?.

Regression

With the nixpkgs version of Python you can expect anywhere from a 30-40% regression on synthetic benchmarks. For example:

## Ubuntu's Python 3.8
username:dir$ python3.8 -c "import timeit; print(timeit.Timer('for i in range(100): oct(i)', 'gc.enable()').repeat(5))"
[7.831622750498354, 7.82998560462147, 7.830805554986, 7.823807033710182, 7.84282516874373]

## nix-shell's Python 3.8
[nix-shell:~/src]$ python3.8 -c "import timeit; print(timeit.Timer('for i in range(100): oct(i)', 'gc.enable()').repeat(5))"
[10.431915327906609, 10.435049421153963, 10.449542525224388, 10.440207410603762, 10.431304694153368]

However, synthetic benchmarks are not necessarily reflective of real-world performance. In common real-world situations, the performance difference between optimized and non-optimized interpreters is minimal. For example, using pylint with a significant number of custom linters to scan a very large Python codebase (>6000 files) resulted in only a 5.5% difference. Other workflows that were not performance sensitive saw no impact to their run times.

Possible Optimizations

If you run code that heavily depends on Python performance, and you desire the most performant Python interpreter possible, here are some possible things you can do:

  • Enable the enableOptimizations flag for your Python derivation. See Example. Do note that this will cause you to compile Python the first time that you run it which will take a few minutes.
  • Switch to a newer version of Python. In the example above, going from 3.8 to 3.10 yielded an average 7.5% performance improvement, but this is only a single benchmark. Switching versions most likely won't make all your code 7.5% faster.
  • Disable hardening. Beware this only yields a small performance boost and it has impacts beyond Python code. See Hardening in Nixpkgs.

Ultimately, it is up to your use case to determine if you need an optimized version of the Python interpreter. We encourage you to benchmark and test your code to determine if this is something that would benefit you.

Troubleshooting

My module cannot be imported

If you are unable to do `import yourmodule` there are a number of reasons that could explain that.

First, make sure that you installed/added your module to python. Typically you would use something like (python3.withPackages (ps: with ps; [ yourmodule ])) in the list of installed applications.

It is also still possible (e.g. when using nix-shell) that you aren't using the python interpreter you want because another package provides its own python3.withPackages in buildInputs, for example, yosys. In this case, you should either include that package (or all needed packages) in your withPackages list to only have a single Python interpreter. Or you can change the order of your packages, such that the python3.withPackages comes first, and becomes the Python interpreter that you get.

If you packaged yourself your application, make sure to use buildPythonPackage and **not** buildPythonApplication or stdenv.mkDerivation. The reason is that python3.withPackages filters the packages to check that they are built using the appropriate python interpreter: this is done by verifying that the derivation has a pythonModule attribute and only buildPythonPackage sets this value (passthru here) thanks to, notably passthru = { pythonModule = python; }. If you used stdenv.mkDerivation then you can maybe set this value manually, but it's safer to simply use buildPythonPackage {format = "other"; … your derivation …} instead of mkDerivation.

See also