Python: maintaining requirements.nix and requirements.txt?

I’ve been experimenting with using nix to manage the development environment for a python-based web app. I initially generated a requirements.nix with pypi2nix but needed fairly significant manual updates to get everything sorted.

I’m pretty happy with how this works, but I’m leery of the potential for mistakes/divergence introduced by having separate authoritative definitions for packages installed in my personal dev environment and the production environment.

Does anyone have or know of good tooling/patterns for maintaining a single authoritative source?

1 Like

I hope that pypi2nix will be able to cache results of single packages at some point. At the moment when a failure, one has to start from the beginning, which takes too much time on complex projects.

1 Like

For what it’s worth, I have had good results to date using GitHub - datakurre/setup.nix: Nixpkgs based build tools for declarative Python packages [maintainer=@datakurre] (which adds some useful helper functions on top of pip2nix (this one GitHub - nix-community/pip2nix: Freeze pip-installable packages into Nix expressions [maintainer=@datakurre] )

I’ve not worked with GitHub - nix-community/pypi2nix: Abandoned! Generate Nix expressions for Python packages so cannot speak to it

1 Like

Thanks for pointing out setup.nix. I’m not sure it will quite solve my immediate concern, but I can think of some other ways to put it to use.

Consider this comment obsolete. There are now good documented options in nixpkgs manual.

FWIW, I’m now happily managing the project mentioned here with mach-nix with most dependencies still specified in requirements.txt.

I never did share the requirements.nix version with the other developer on the project, but the mach-nix version has been stable enough for us to share even though he has minimal Nix knowledge.

I haven’t had time to evaluate whether moving to dream2nix is ripe yet.