Yann B眉chau 
Lol no I just forgot I had nix-ld enabled 馃槄
Marcus@nobodyinperson nix-ld is great. basically essential for me to use lazyvim.
BB 
@nobodyinperson: time to write that sync script I mentioned? 馃槄
ZeStig 
@nobodyinperson is it that powerful? What does it do?
@zstg Apparently it just installs a dynamic link loader thing in a normal location where programs expect it and thus makes precompiled binaries that look for libraries work. Feels like a lightweight FHSEnv just for compiled libraries? 馃
@nobodyinperson: depends on the libraries you need, tbh. If you're doing something "easy", yeah - probably. If you need wheels linked against system libraries or something: likely not.
@BryanBennett No I mean exactly that. numpy suddenly just works, without my buildFHSEnv wrapper. I don't understand it, but I like it 馃槃
@nobodyinperson: in my experience, there were still many things that fail. (python-magic, if I remember correctly?)
We just build derivations for our Python projects these days. With some limited knowledge and some basic tooling (or slightly more knowledge to not require the tooling), it is pretty easy to form an overlay and use that in a `python3.withPackages` invocation. The big problematic libraries are mostly packaged and the smaller ones are trivial to add.
But I totally understand not wanting to do that :P
@BryanBennett Yeah that's what I'd do if I was the only one using it, but I want/need to keep it compatible with a non-nix workflow. I just tried #uv2nix but of course it failed on some super weird "license" key in pyproject.toml in a downstream depencency ("calver"!?) and of course there is no documentation on how to fix that 馃檮
I'll see if uv on its own works well enough on NixOS and non-NixOS. For now it seems so.
@nobodyinperson: we actually maintain two environments: one nix-native and one Python native, but pinned to nix available versions. This allows people to "preview" the environment manually with python native tooling. We require changes to package versions (or new dependencies) to go through the nix native tooling as it is the more restricted set of available versions (if you want to stick to a single nixpkgs revision...), but this is okay as we mostly have a few senior (and nix knowledgeable) developers adding packages and updating infrastructure and more mid/junior developers using the tooling. Maybe that works for you?
@BryanBennett Manual pinning (with uv or poetry or whatever) to nixpkgs versions is a fun way to keep the two in sync. But it's one manual step too much for me. I guess I need to decide if I want to keep the non-nix compatibility at all or just require everyone to use nix. 馃
Sean@nobodyinperson @BryanBennett I wonder if pixi (https://pixi.sh/) would work (by using conda packages) for cases something goes wrong due to system libraries.
Unlike regular conda, the environment is located inside your project folder might make things easier on nix as well, but I haven't tried this out myself.
In addition, pixi uses uv under the hood for normal `dependencies` declared in your `pyproject.toml`
Unlike regular conda, the environment is located inside your project folder might make things easier on nix as well, but I haven't tried this out myself.
In addition, pixi uses uv under the hood for normal `dependencies` declared in your `pyproject.toml`
@nobodyinperson: it REALLY isnt that hard. The python native pin is often something very loose that nix can fulfill, such as the major version. Just something we can somewhat rely on to tell us if they drift too far apart.
In the other cases, it is an exact pin (which is eminently scriptable) that means that they all get invalidated when the nixpkgs revision gets updated and because we have scripted the initial pinning, we scripted the update pinning too. I think I might like this one better overall as it is a very natural fallout of the nix environment.
Basically, you build the nix environment once and then iterate all your dependencies and parse the version string out of the nix store path and pin to that +/- some exceptional libraries that need different versions because the nix provided version doesn't match their pypi version. It is a bit tedious but not hard and the bulk of the tediousness is done exactly once.