undefined | Better HN

0 pointsfer1mo ago0 comments

nix develop ensures your dev env is the same as your build/test/prod env. At least with Python everything is a flurry of requirements.txt, Python versions, poetry, pyproject.toml, perhaps automated with direnvs, a hefty Dockerfile/docker-compose, and perhaps conda (ugh) along the way; lots of moving parts.

I have a project that's mostly Rust sprinkled with C++ libs and Python helpers and it's easier to manage than the average virtualenv. Everything builds with nix build, everything runs with nix run, profiler/debugger works, IDE detects everything on any of my computers, builds and links with CUDA on x86, aarch64, NixOS, MacOS, Ubuntu or Amazon Linux. nix build can even build a Docker image for the odd need of Docker, and I haven't tried but I'm convinced that if I import the flake on my nix-config it will be built into the SD card for my Raspberry Pi just fine.

It's even replaced Ansible for me, colmena all the way.

0 comments

2 comments · 1 top-level

chrisweekly1mo ago· 1 in thread

Pythonistas have mostly moved to uv, which solves much of the "flurry" you describe. Tools like Mise add more of the benefits ascribed to nix. And smolmachines' smolvms can provide better isolation than Docker. Just saying, TIMTOWTDI. Not hating on nix, just pointing out it's not the only game in town.

sshine29d ago

Nix is like Borg of Star Trek: It assimilates everything.

I'm not a Python developer, but I follow the news, and I agree that uv is the future of Python package management.

So if you're a Nix user and you want Nix to be opt-in, and you love uv, you use uv2nix, declare the uv lock file the source of truth and build your Nix derivations on that. When the hashpins live in the uv lock file, uv works just fine, but uv2nix produces derivations that are cached and can be embedded in CI or deployment strategies.

So... running CI on your uv-based project means your Nix tooling can cache both tooling and dependencies.

And... deploying your uv-based project you can build an OCI image with the same source of truth as the dev/CI environments.

This matters more for toolchains that YOLO more wrt. dependency pinning: Does that CLI call in your Dockerfile really pull the same thing down just because it's still v6.6.6? Some package managers provide a lot of sane choices, and I'd bet uv is one of them. But your Dockerfile is always a second-grade citizen unless you re-use the same base as a devcontainer.

j / k navigate · click thread line to collapse