Update: I have tried mainly
poetry2nix to get a
nix-shell env equipped with the Python dependencies. I started with a
nix-shell env instead of a Python application, because this is the easiest way to incorporate Nix into Zulip’s provisioning, for now.
mach-nix can read from a requirements.txt directly, it fails to read Zulip’s lockfile requirements files, because they contain explicit integrity hashes, as can be seen here
I can contribute upstream to
mach-nix for the
--hash=... feature, but this means that the feature is not available now.
Edit: it could be intentional that
mach-nix doesn’t parse
--hash=..., see Mach-nix, pip2nix, poetry2nix, or pynixify for Zulip provision - #16 by rht.
I had to manually convert the requirements files to pyproject.toml and poetry.lock, but other than that, it works out of the box!
Uses wheels by default. But I am not able to even run
pip2nix in a
nix-shell due to this issue. I’m testing on a NixOS on the unstable channel, while
pip2nix requires running
pip2nix generate -r requirements.txt on the stable channels.
Has the same problem as
pynixify can’t parse
--hash=.... Even if this is addressed,
pynixify still has limitations with version pinning, as stated here. It recommends not using
# A great requirements.txt file
pynixify relies on pinning the Nixpkgs version instead. And the Python package versions are constrained to be the versions specified by the pinned Nixpkgs. As such, I think using
pynixify is a no-go.