You canât âpinâ something to an effectively randomly changing value, that doesnât make sense.
However, if you set the url
to the name of an entry in your flake registry, the flake from your flake registry will be taken as an input. You can also omit the entry in the inputs
attrset, and make the name of your outputs arg match an entry. If you donât want to pin your nixpkgs version for a specific project for whatever reason, you can do that.
E.g.:
{
outputs = {nixpkgs, ...}: {
# stuff
};
}
or more verbosely:
{
inputs.nixpkgs.url = "nixpkgs";
outputs = {nixpkgs, ...}: {
# stuff
};
}
Of course, you can just use follows
as usual to override input flakesâ recursive dependencies.
Note that whatever your system flake points at is usually not the same as what your registry points at, but you can configure them to match: https://github.com/TLATER/dotfiles/blob/7c09f2c1fd4b2ba96aeffe67435a05f076cfec48/nixos-config/default.nix#L42
Doing it like that, and setting the flake inputs of your system flake to non-registry entries, will effectively âpinâ your registry entry to whatever your system entry is pinned to. This is still random - or at least untraceable - as far as any consuming projects are concerned, though.
I think doing the inverse of this is probably better practice by the way, there were some caveats to the above that I forgot.
Note also that the flake registry by default sets nixpkgs
to the unstable branch, and updates this automatically when you run nix commands after a time out of - I believe - a few hours. This is also why e.g. nix run nixpkgs#package
will almost always download stuff by default (the latest nixpkgs unstable).
You can pin your registry to work around this, and/or set it to stable, but now youâve just reinvented channels with all the issues having an imperative component to your system and all projects has.
So weâve gone back in time to before niv
or fetchurl
-ing specific nixpkgs revisions was a thing. Depending on what you wanted, this may be good, and I think the fact that this isnât the default way to use flakes while still being an option is nice.
I would definitely not recommend this for projects you intend to share with anyone, in either case. For those kinds of projects, offer a canonical version of nixpkgs they will work with. If dependency duplication becomes a problem, or maintenance/short-term vulnerability issues arise, override the inputs with follows
on the user end, and/or wait for something like flakehub to come into general enough use that the problem is mostly kept in check.