I try to find a way to test a new version of a locally changed package within my system configuration.
I saw there is a new pipewire version so i took the pipewire folder from nixpkgs and modified version and hash in default.nix:
There is no error but after nixos-rebuild switch pipewire is still on version 0.3.48 despite that 0.3.49 got build and is available in the store.
(I restarted the computer to be sure its not just that systemd havn’t been updated sufficiently) I see that the recommendation is to keep the change of the package within nixpkgs, but I want to understand why my attempt doesn’t work.
solution:
I looked in the wrong way for the version that is used by systemd and in my user-environment i had a version that covered the version of pipewire that is used by cli. I just had to uninstall that to reduce confusion.
Where are you checking this version? Did you restart the service, and/or computer? It being in systemd.packages makes me wonder if it requires a full systemd restart to take effect.
If you’re using pipewire --version, any chance you have the nixpkgs version in an environment.systemPackages somewhere, causing that to mask the one added by services.pipewire.enable?
Personally I would create an overlay and use overrideAttrs to change the version used in the pipewire derivation, but copying the directory and callPackage-ing is effectively doing the same thing, so something else must be wrong.
Oh, also keep in mind that the version attribute may well be set to the old version, in which case it will look like the package hasn’t updated, but that’s just cosmetic.
Systemd should warn about that, though, and restarting the whole device will have the same effect… I’m stumped at this point. I’d check what binary the unit is actually running with systemctl status, and if that’s the correct version figure out where the version from my PATH is coming from.
Ah, yes. Anything installed with nix-env isn’t coupled to the system configuration, but your “profile”. This is doubly bad because root has a separate profile which will get very confusing if you’ve ever stuck a sudo in front of that, as many people do out of package installing habit from other distros. Using nix-env on NixOS is an anti-pattern, it leads to situations like this - probably the 10th time or so I’ve actively been confused by this myself, if usually through others not mentioning they use it
Just remove all your nix-env’d packages, use environment.systemPackages in the future and forget that command even exists.
I got into using this because whatever I tried, the installation didn’t change. But the problem was that i didn’t update the hash. Is this a bug in fetchFromGitLab or expected behavior? I needed to add a wrong hash first to get the new one. I would expect to that a rev/version change would lead to the error the wrong key triggers.
I don’t know in detail what happened with your experiment here, but rather than using a “garbage” hash I’d suggest using an empty string. Nix will then use sha256-AAAAAAAAAAAAAAAAAAAAAAA or whatever, which is much easier to spot as a garbage hash than a valid one.
what happened was that only changing version didn’t trigger any error.
Setting rev = "0.3.49"; just recompiled (not even sure about that) and wrote the old version into a new folder with the new rev/version name.
Yep! That’s expected. Nix uses the checksum to assert whether the input has changed, if the checksum doesn’t change obviously the input didn’t change so you can skip the download. If the user supplied a false checksum with their input that’s on them. See the nix pills section on the topic of fixed-output derivations. It’s how you get to download things in the otherwise pure build system, since normally external dependencies and side effects aren’t allowed.
I think in this case it will rebuild, because you updated the version in the derivation, so the derivation changed and it must rebuild in case there was an actual meaningful change. To my knowledge there are no intermediate build output caches.
