I added it in my nixos config, and it’s pretty great. I put it on my blender version and now I don’t have to evaluate another nixpkgs just because I got blender slightly behind if I build a machine without blender.
However, I have a special use case where I want to pin by derivation hash, not commit nor version. The only reason why I’m pinning blender is that I need to recompile it with CUDA everytime there’s a dependency getting updated (AKA 4 hours of 100% CPU usage).
Would be great to be able to pin the derivation hash, and let the multiple nixpkgs solver do its thing instead of explicitly pinning the commit
With just plain NixOS you can do environment.systemPackages = [ /nix/store/pkf547jp8a92k4wmxikkyby58w10pysr-bash-interactive-5.3p9 ];
(no need for anything in this thread, etc.) Or you could manage this particular package “imperatively” via nix-env or nix profile. I mean, no need to deal with nixpkgs git commit in this case, I believe (and re-eval all the time, etc.)
Imperative: what you described sounded like imperative updates to me, but sure – I just added one simple option and everyone picks whatever they like best
By this do you mean you just want to keep the store path you’re currently using? Cause if so, you can manually link the path to the GC root to keep it from getting GC’d. I do this with citrix-workspace.
Nah. What I want is to compile the version once, and keep it as is until the next one. Even if the dependencies update, it must stay like that.
I don’t want to spend 4 hours recompiling just because python updated or something like that. I can wait the next blender version
Manually linking it is more annoying as I need to build it, then link it, when I can just put a reference to a commit instead and everything’s done for me
That’s not really how nix works, unfortunately. Updating python changes blender too. pkgs.blender resolves to different packages depending on what nixpkgs rev you’re using. This is intended, since an updated dependency will change functionality somewhere.
That said, using multiverse you can probably write a function that looks for the newest version of blender, checks if it’s significantly newer than your current one and conditionally add it to systemPackages.
I read somewhere that something like this may be possible with dynamic derivations in the future.
I just had an idea and used Claude to create a POC. Other tools like mise support reading version files like .nvmrcand then loading the correct Node version. We can do that too.
Sick!
Try piping it through grail (although that would be an IFD) if you want to minimize the resolution and maybe consolidate to 1 glibc or something.
