Nix(OS) for Python Developers · Painless
Nix(OS) for Python Developers · Painless
Nix(OS) for Python Developers · Painless
cross-posted from: https://programming.dev/post/34879040
Nix(OS) for Python Developers · Painless
Nix(OS) for Python Developers · Painless
cross-posted from: https://programming.dev/post/34879040
Finally got to a Python question
On Nix(OS) can i setup a python development environment from requirements files without ruffling the package managers feathers?
When ready to create a wheel, python -m build
, how does Nix(OS) want the python package to be built to gain all the benefits of Nix(OS) build reproducibility?
If you just want to quickly create a local python develop environment on the side using Python module metadata, installing uv
from nixpkgs, and enabling nix-ld
to run pre-compiled binaries from PyPI keeps things simple, and replicating the same virtual python environment workflow you to have on any other distribution:
https://discourse.nixos.org/t/i-want-understanding-nix-packages-and-flake-basics/67365/3
If you wanted to package a python module for nix or for proper distribution via nixpkgs, you'd want to add a nix derivation file that encapsulates all the inputs, i.e. software building materials (SBOM). There are existing nix library functions that can automate most of the packaging, not unlike Debian macros:
https://wiki.nixos.org/wiki/Python
The second approach is more rigorous, and combined with something like flakes for pinning the exact hash for all inputs via lock file ensures reproducibility, like when sharing with other nix users. While as the first approach is more subject to your current system, i.e. linking to whatever system wide libraries are presently installed, but it's less upfront effort to reuse existing python-package-managers than to nixify everything.
ok fine lets talk about this Linux distro
Don't want to be a package manager database on my off hours. Why is having users manage every transitive dependency a good design?
I'm asking i really don't understand the merits of adopting this heavy burden
I'll preface that NixOS may not be for everyone, as deviating from a conventional hierarchical file system is a radical departure from conventional distributions; but for those that want precise control over their system environment, it has a good deal of appeal.
For example, I appreciate being able to use the latest bleeding release of a number of tools while sticking with older trusted versions of other utilities, but if both relied upon different versions of similar dependencies, such package conflicts can be troublesome to resolve, as few Linux package managers gracefully deal with multi version installs.
For NixOS using the nix store, installing leaf packages that traditionally conflict is trivial, and as a user, I can spend less time managing every transitive dependency in order to use the software I want. Not having to wait for a disjointed ecosystem of packages to synchronize around dependencies, or resorting to compromise in package version selection is very liberating.
The functional language and documentation for nix itself is a bit quirky, as I wish it was stronger typed, but being able to declaratively express and version control my setup across workstations has been a time saver; installing/configuring something once and then have-done with it.
Being able to have different package versions live side by side, is mind blowing. Most people would resort to flatpak or docker to contain that packages dependencies and transitive dependencies. But the amount of redundant packages must be mind blowing.
To not need all those redundant packages is an impressive feat!
This is a Linux post. Has nothing to do with Python
I would have liked the PyCon25 talk directly, but I don't think the recordings have been published yet:
https://slides.com/bittner/pycon25-nixos-for-python-developers#/2/4
Hopefully the presenter discusses more on their later slides in using python on NixOS and working around python packaging's use of dynamic linking.