A few flake-related questions

frozen.frog23 · May 19, 2025, 3:37pm

hello everyone! noob here…

so, about -> follows 'nixpkgs'…

what should one use that for, if a flake works just fine without it? is it for compilation tools or something? because if every flake uses its own built-in, independent compilation tools, does that mean that with PKG.inputs.nixpkgs.follows = "nixpkgs" one can use system packages and compilation tools instead? okay, then, how do i even know that it does, indeed, do exactly that? i.e. how do i see if it builds / compiles using my own compilers from my systemPackages / nixpkgs? or did i get that completely wrong and am a fool? e.g.:

inputs = {
  # ...
  yazi.url = "github:sxyazi/yazi"; # necessary for installation
  # yazi.inputs.nixpkgs.follows = "nixpkgs"; # not necessary?!
};

sometimes, the latter line could lead to compilation errors and to hash mismatches in fixed-output derivations. but why?

how does one know when is it possible to use a PKG.inputs.nixpkgs.follows = "nixpkgs"? do you actually have to look at each and every flake to see if it supports it?

okay, here is another one: i just want A package from a flake which is NOT in the main nixpkgs repo (is that how you say it?). a singular package. that’s it. is this the bare minimum for unstable?

flake.nix

{
  description = "help me"; # is *description* even required?
  inputs = {
    nixpkgs.url = "github:nixos/nixpkgs/nixos-unstable";
    yazi.url = "github:sxyazi/yazi"; # file manager 
  };
  outputs = {
    self, 
    nixpkgs,
    # yazi, # do you need this output? why?
    ...
  } @inputs: # sorry what? WHAT IS THIS?!?!
  # sometimes they do even THIS:
  # @inputs: let inherit (self) outputs; in # WTF?!
  { nixosConfigurations.HOST = nixpkgs.lib.nixosSystem {
      system = "x86_64-linux"; # LEGACY?! do you still need this? 
      specialArgs = {
        inherit inputs; # why? why? whyyyy?!
        # or
        # inherit inputs outputs PKG; # please help me
        # or
        # inherit inputs nixpkgs; # i am utterly lost
      };
      # ... 
      # sometimes people have more stuff HERE
      # ...
      modules = [
        ./configuration.nix # understandable
        # ./hardware-configuration.nix # NOT understandable!!
        # yazi.nixosModules.default # unnecessary? why would you want this?
      ];
    };
  };
  # ...
  # again, some people have EVEN MORE stuff down here! 
  # ...
}

configuration.nix

{
  config, # config = { }
  lib, # mkDefault mkForce
  pkgs,
  inputs, # flakes
  ...
}:

{
# ...
  environment.systemPackages = {
    inputs.yazi.packages.${pkgs.system}.default;
    # okay, SLOW DOWN. what is all of this:
    # ${pkgs.system}?
    # is it the same as
    # ${pkgs.stdenv.hostPlatform.system}?
    # next, why doesnt it work without *inputs.*?!
    # in some guides they just tell you to
    # "place the pkgs.PKG in *systemPackages*"
    # but it never worked!
  };
# ...
}

lastly, this question bothers me the most. could be a little silly, but i do need to ask this:

for example, i am NOT using nixos-unstable, rather, i am using nixos-unstable-small. do you have to accommodate for the prefix or not? for example:

inputs = {
  # nixpkgs.url = "github:nixos/nixpkgs/nixos-unstable";
  nixpkgs-small.url = "github:nixos/nixpkgs/nixos-unstable-small";
  yazi.url = "github:sxyazi/yazi";
  yazi.inputs.nixpkgs.follows = "nixpkgs-small"; # is that right?
};

i just really want to understand this before i go ahead and try home-manager. which has like 3 different ways of installation inside a flake.nix: the external .nix file configuration, the nixosModules configuration - the one that is strangely without the equals mark before { }, and a separate homeConfigurations."USER@HOST" = home-manager.lib.homeManagerConfiguration - all of them are just… infinitely interesting.

sorry, it surely is quite a bit silly, but, yeah… thanks in advance!!!

P.S. i DONT use yazi nor home-manager…

LATE EDIT: hey guys, future me here. dont wanna bump this, but here is how i do it nowadays. pls let me know if this is bad practice lol.

so im gonna show u how to install a flake package and extra flake options, such examples are niri and hjem respectively:

flake.nix

{

  inputs.nixpkgs.url = "https://channels.nixos.org/nixos-unstable/nixexprs.tar.xz";
  # ^ this doesnt use github at all and shrinks size! ^
  
  niri.url = "github:niri-wm/niri"; # package(s) example
  niri.inputs.nixpkgs.follows = "nixpkgs";
  # ^ this uses system nixpkgs and shrinks size! ^

  hjem.url = "github:feel-co/hjem"; # option(s) example
  hjem.inputs.nixpkgs.follows = "nixpkgs";
  # ^ ditto, uses system packages when building! ^

  outputs = inputs: { # shortens a duplicate list...
    nixosConfigurations.HOSTNAME = inputs.nixpkgs.lib.nixosSystem { # FIXME!
      specialArgs.inputs = inputs; # same as "inherit inputs"
      modules = [
        ./configuration.nix # inputs
        # niri flake is just a package without options!
        inputs.hjem.nixosModules.default # options
      ];
    };
  };
}

^ well technically every module contains a package, but y’know what i mean, right?

configuration.nix

{
  config, # shortens the options
  inputs, # passes the flakes
  lib, # the "lib" part in "pkgs.lib.mkForce" et al
  pkgs, # the "pkgs" part in "pkgs.niri"
  ... # the rest of the dictionary
}: { # actual "config.*" shorthand per se

  programs.niri.enable = true; # vanilla nixos
  programs.niri.package = inputs.niri.packages.${pkgs.stdenv.hostPlatform.system}.default;
  # ^ comes from "niri.url" in "flake.nix" ^
  # ^ its very messy, but it works! ^

  hjem.users.USERNAME.enable = true;
  # ^ comes from "inputs.hjem.nixosModules.default" in "flake.nix"
  hjem.users.USERNAME.files.".bashrc".text = "";
  # ^ just for show, creates empty ".bashrc" at "$HOME" ^

}

and thats it! to update the system, i use nh (nix helper). since i keep my configuration.nix and flake.nix in $XDG_CONFIG_HOME/nixos ($HOME/.config/nixos), i have to set a path:

configuration.nix

  programs.nh.enable = true; # vanilla nixos
  programs.nh.flake = "$HOME/.config/nixos"; # sets $NH_FLAKE
  # ^ it cant find "$XDG_CONFIG_HOME" for some reason? ^

after which nh commands will be available, so that i could update everything with these:

A) if i want a full system update (with flake inputs, SLOW):

nh os switch --ask --diff=always --keep-going --update --verbose

B) if i want to refresh configuration.nix (without flake inputs, FAST):

nh os switch --diff=always --keep-going

anyway im not gonna yap about how to use literally anything, but this was relevant to my usage of flakes lol

…so yeah! that is how i use my little nixos system! i am very much chaotic, so i dont “split” my configs or anything, everything is all piled up in one file, dont care. ive been saying this for a long time now, but i still dont have my own repo. i really wanna share this, but its not ready even at 20k lines… bye bye!!!

^ END OF LATE EDIT ^

TLATER · May 19, 2025, 3:59pm

Not system dependencies, but the same nixpkgs as the one specified in your flake (or your flake registry, if you don’t define nixpkgs in your flake).

This is important, because without it, every single flake you import will have its own copy of nixpkgs, meaning that every flake you use roughly doubles your system closure size. You also have no control over when your recursive inputs update if you don’t set it, meaning you have to rely on all upstreams adequately updating.

I find it strange that it would lead to that in fixed output derivations, the fetchers would need to change for that, which is very uncommon. Maybe you’re making it use very outdated versions of nixpkgs?

However, errors when you do that are quite expected. It’s not unusual for dependency versions to change, becoming incompatible with the flake’s actual source; you’re substituting a different set of versions after all, there is no guarantee that this will work.

Pretty much. You also have to check their recursive dependencies. You check if their inputs contain a nixpkgs; if they do, you can change their nixpkgs to yours with .follows. You can do this for all other inputs, too (though luckily it’s usually less essential than for nixpkgs).

To see if it will be successful is trial-and-error. In addition, some flakes depend on nixpkgs multiple times, so you even have to check if your substitution actually deduplicates as you intend it to.

Yep, you do have to do that.

All of this is one of the glaring design flaws of flakes which haven’t seen much attention in the last 5 years (besides subbing in a proprietary web service, promising to eventually work with the community to release a proper fix to the schema, and then just leaving the flakes concept to rot).

My personal suggestion is to just ignore flakes for now, at least for NixOS systems - you barely have a use case for them, npins can do all of the input management just fine. But I suppose you’ve already started going down the route.

Ignoring .follows is fine, but it has a lot of downsides. Specifying it is fine, too, and has fewer risks, but involves a lot of drudgework, understanding of the dependency tree, and trial-and-error. Flake inputs are unfortunately kind of inherently broken.

waffle8946 · May 19, 2025, 3:59pm

follows shrinks your lockfile size, nothing more. It increases the chances of incompatibility and you have to manage that as it arises.

Also you probably don’t want to use -small, it’s going to have less packages cached.

frozen.frog23 · May 19, 2025, 4:21pm

oh wowie, thank you guys, A LOT!! i will certainly try npins, im completely fine with trying new stuff. but yeah, i definitely wasnt expecting such a hasty reply, i was in the middle of editing and adding another question, which is about… the minimal requirements to install A flake package (see above). could you please give some light on that?

and yeah, i know, less cache, but i am literally only using TUI stuff. im that kind of person… lolz

by the way… speaking of unstable-small… who dictates which kind of packages get the cache?

TLATER · May 19, 2025, 4:29pm

You’ll have to expand on what you mean by that. I suppose the “minimal requirement” is a nix version that supports flakes, which is practically all of them now?

You’d be surprised, you can easily eat another 30G of space just from bonus stdlibs if you have a sufficiently deep flake tree. Not to mention the cost in evaluation time and memory use; each separate nixpkgs instance takes about 250MB, so with just 10 you’re nearing 3GB of memory use every time you evaluate your config (assuming each instance is actually used).

And again, you’re not getting updates at the cadence you expect when you run nix flake update, which is a pretty big deal.

It’s defined here: nixpkgs/nixos/release-small.nix at master · NixOS/nixpkgs · GitHub

The answer to who is responsible, well, the nixpkgs contributors. You can send PRs in yourself, if you have a reasonable argument for why something should be in there.

It’s not intended for desktop use, though, so since you’re using home-manager I agree with @waffle8946 here, you shouldn’t be using a *-small channel, it just forces you to build lots of software locally that you don’t need to build; sometimes waiting an extra day for an update isn’t going to cause issues for you.

frozen.frog23 · May 19, 2025, 4:33pm

sorry, i have edited my original post, the question is there, in the middle. uhm, about compiling. okay, then i shall switch back for now. i will be soon getting a ridiculous 128 core ARM monster that i will be using as a uhm, a substituter? you know, the remote builder. what do you call them…

p.s. i’ve heard that i could contribute to the binary cache by providing my own computational power - they probably phrased it better than me, but i wonder how easy it is to actually do that? i bet you need to go through lots of security checks first… i probably will be using these 128 cores for my personal use, but… im just wondering if i can help anyhow

TLATER · May 19, 2025, 4:44pm

Ah, I see, lemme reply to your comments.

You can keep it empty if you like. It’s nice for documentation purposes.

That’s not an output, it’s your input. It passes your input’s actual value into your output function; without it you can’t actually use the yazi input.

That said…

It’s nix syntax for “take all the stuff from the destructured attrset being used as a function argument that precedes this and also put it in this variable”.

It basically lets you also say inputs.yazi and inputs.nixpkgs, instead of using the nixpkgs and yazi bindings you defined previously.

This seems niche, but especially for flakes it’s super useful, because:

Right, so specialArgs lets you inject things into the modules you define. That’s jargon - you know how in your configuration.nix it starts something like this?

{ pkgs, lib, ... }: {

}

Ever wondered where the pkgs and lib come from? Well, they’re defined by the nixpkgs modules, and you can use specialArgs to add your own.

So when you do:

specialArgs = { inherit inputs; };

# btw that's just short for:
# specialArgs.inputs = inputs;

You can now do:

{ pkgs, lib, inputs, ... }: {

}

And this is super useful, because now all your flake inputs are accessible from your configuration.nix through inputs, which means you don’t have to do any of the hacky stuff that lots of people do in their flake.nix (some of which you seem exasperated by) because they don’t understand NixOS.

Hacky stuff like this

Yeah, that’s stupid. outputs is available through self if you inherit inputs, nixpkgs is available through inputs.nixpkgs. PKG is likely retrieved using a inputs.nixpkgs.legacyPackages......, which you could just do in configuration.nix.

Don’t learn from people who do stuff like that.

I’m aware! For NixOS systems, you rarely ever need more stuff. Just ignore it unless you know how it works.

Someone wanted self to be renamed to outputs and wrote that code in the most confusing way possible. Or they hve no idea what they’re doing and were throwing shit at the wall until it evaluated. Don’t copy that.

Yeah, if you just want a single package that’s unnecessary. If you want to use the module defined in the flake, you need it. I don’t use yazi, but lots of software packaged for NixOS needs to be activated with a module, so perhaps you need that.

Either way, you shouldn’t put it in your flake.nix. Instead, put it in your configuration.nix, using the specialArgs trick as explained earlier:

# configuration.nix
{ inputs, ... }: {
  imports = [
    inputs.yazi.nixosModules.default
  ];
}

or, if you really just need a package:

# configuration.nix
{ pkgs, inputs, ... }: {
  environment.systemPackages = [
    inputs.yazi.packages.${pkgs.system}.default # Or .yazi, depends on what they define
  ];
}

TLATER · May 19, 2025, 4:49pm

Oh, more questions:

frozen.frog23:

    inputs.yazi.packages.${pkgs.system}.default;
    # okay, SLOW DOWN. what is all of this:
    # ${pkgs.system}?
    # is it the same as
    # ${pkgs.stdenv.hostPlatform.system}?

Yep. The point is, flake outputs require specifying the platform of the package you want. This is because cross-platform builds are first class citizens in the flake world. So you need to know the system triple for the system you’re deploying to be able to pick the correct package. That does that.

Well, as I explained in my previous post, you’ve passed inputs into specialArgs. So the only handle you have for the yazi flake packages is inputs.yazi.

You can also define an “overlay”, which injects all the yazi packages into your nixpkgs’ pkgs. This used to be how people depended on third party package repositories with NixOS, but nowadays it’s basically just done because people haven’t realized specialArgs exists yet. It’s a bad idea to use overlays and flakes together most of the time, unless you actually want to override a package in nixpkgs. You can mostly ignore those guides.

frozen.frog23 · May 19, 2025, 4:50pm

oh that is extremely useful! well done!

yeah… i always had these INTERESTING lines commented out… i always wanted to ask what are they even for… now i know. thanks a lot!!

very interesting indeed… but

what about specialArgs = attrs;? is this for channels?

also, one more final question. perhaps a very difficult one. so… how do i even put this. getting A package from a flake that is literally just A package (singular) is easy. but what if… what if the flake has A LOT OF THEM? such as:

chaotic.url = "github:chaotic-cx/nyx/nyxpkgs-unstable"; # what
jovian-nixos.url = "github:jovian-experiments/jovian-nixos"; # the
nur.url = "github:nix-community/NUR"; # NUR?!

and i only want just that SPECIFIC one? e.g. a pkgs.steamdeck-firmware from jovian-nixos flake. they basically tell you to install the whole thing. NO, i want just “that” package. but how?!

is it possible to NOT compile every single stuff in the flake and instead choose only those that one would want? or do i completely misunderstand flakes? what happens when you add ONLY the input? does it begin to compile only after i give it an inputs.PKG.packages.${pkgs.system}.default; - is that right?

ahh… im just a question making machine at this point. but there is just so much stuff, honestly. i mean, SOME flakes come with sha256 hashes that you have to somehow get. i’ve heard one way to do this is via sha256 = lib.fakeHash; - to let it fail and reveal an actual proper hash.

AND THEN, it just never ends. people use stuff like builtins.fetchTarball to download a tar archive. BUT WHY?! that doesnt look right. is that even technically a flake? am i wrong? why do other flakes work without this?

…

also… about CUSTOM flakes. quite literally. so to make a FLAKE.url = "github:USER/THING"; actually work you will need a flake.nix in the repo, correct? what if there is none of that? for example, i want THIS - durdraw, which is not in the repo. i could A) issue a PR asking for this to be added to nixpkgs or B) …what else? use fetch*? how can i make this work with flakes? or can i literally just compile that myself? that wouldn’t be very nix-way-ish, right?

that is a lot of question marks!

frozen.frog23 · May 19, 2025, 5:30pm

sorry, i could not resist just a few more flake-related questions… i still had lots of spare question marks lying around (see above)

fricklerhandwerk · May 19, 2025, 5:38pm

Nit: this is not exactly true. In the flake world, you’re merely forced to make the system string explicit. This has nothing to do with cross compilation which is a downstream concept that lives entirely in Nixpkgs. Nix is not aware of that, all it knows is which system a derivation‘s builder executable will run on, which can be used e.g. to dispatch remote builds.

Other than that, thanks a lot @TLATER @waffle8946 for the detailed replies! @frozen.frog23 consider to take it more slowly with Nix and first go through the most important tutorials that should help get an idea for what’s even going on:

frozen.frog23 · May 19, 2025, 5:48pm

oh, okay! i mean i am taking it slowly, i’ve started in… january this year and look how far i’ve gotten, incredibly!

no need for a vm when the system’s this stable, haha

TLATER · May 19, 2025, 5:51pm

@fricklerhandwerk is right that you probably should slow down a lil’ and look at the docs; but since you have more specific questions and it’s right before bed, let me just quickly knock those out:

Yep. Other packages will usually be available in the same attribute, actually, so you can just:

# configuration.nix
{ pkgs, inputs, ... }: {
  environment.systemPackages = let
    chaotic = inputs.chaotic.packages.${pkgs.system};
  in [
    # I have no idea what packages would be in that flake
    chaotic.firefox
    chaotic.alacritty
    chaotic.etc
  ];
}

NUR is more complex because it’s a historic thing, you will likely need to use overlays for it. But I find myself never reaching for the NUR nowadays.

You misunderstand; that’s not “flakes”. See the docs on packages, there’s a huge difference between a fixed-input derivation and a flake.

Erm, it’s not “a flake”. It’s just a fixed-output derivation. Such derivations could contain nix code, and that nix code may be a flake.

You should not be importing nix code from derivations like that in either case, use flakes or npins instead.

It’s mostly used in guides that insist on having things be short and self-contained at the cost of being more confusing and pushing footguns into people’s hands. The better ones - like what @fricklerhandwerk links - at least eventually also tell you how to do things properly.

That’s correct. The flake syntax lets you define flake = false to put non-flake stuff in your inputs. You can then manually import the - usually - default.nix:

# configuration.nix
{ inputs, ... }: let
  some-custom-thing = import inputs.some-custom-thing { };
in {
  environment.systemPackages = [
    some-custom-thing
  ];
}

The big difference is that flakes define a default set of outputs that you can rely on; i.e., you know that .packages contains the packages included in that flake.

If you use a non-flake dependency, you’re in the wild west, and need to figure out how to use the repository on your own. It might be that default.nix contains a package and that the above works. It could also contain a nested set of packages and you might need to do more stuff. It might not even have a default.nix in the root directory and the above fails miserably.

This is one of the two~ish problems that flakes set out to solve, so unfortunately, there is no real alternative, besides reading repository documentation and understanding nix.

frozen.frog23 · September 4, 2025, 4:12pm

hey guys. mind if i ask a few more? i just dont wanna make another thread, i want everything to be in one place, is that okay? terribly sorry if that is not okay…

so, i dont get “cross compilation”, completely. perhaps NOT in the literal sense (like nixpkgs.crossSystem), but rather in whatever the hell flakes do when they compile/build for every single platform/architecture? such as with rust applications, when there is no binary cache (cachix) - they tend to compile for x86_64-windows, for i686-linux, for aarch64-linux, etc. etc.

but why? i have these set in my configuration.nix:

  nixpkgs.hostPlatform.system."x86_64-linux";
  nixpkgs.buildPlatform.system."x86_64-linux";

and in flake.nix:

  nixosConfigurations.HOSTNAME = nixpkgs.lib.nixosSystem { system = "x86_64-linux"; };

and yet it still compiles for other platforms? why? is this only a rust thing or is that how flakes work and i need some more lines of code to nudge it towards a certain platform? i really wanna know, cos it takes suuuuch a long time to download/compile anything (x86_64 moment), so i wanna minimise the amount of “collateral building”

…

and um, last one, that i found about recently… flake inputs as commits, pull requests, branches, references and revisions! i dont know what any of those mean…?

i found this:

https://nix.dev/manual/nix/2.28/command-ref/new-cli/nix3-flake

but i dont really understand where does it pull from by default, specifically? always from the master branch and the last commit, or? sorry, i dont really know git, i have yet to figure out how to upload my configs on there… ive only recently found about git tag and git checkout, yeah.

speaking of which! how do i “downgrade” a flake? for example, i want a version v3.0.0, but it downloads the latest by default, which is v4.0.0?

and, the opposite: can i force a flake to always download the latest-latest commit/revision/pull request, at all times? without the random numbers in the URL?

i am trying to take it really slow, and i am, perhaps a bit too slow, because everything is just beautiful and i dont want to do anything because i might break things (again). but i want things that arent in the repo! and i am getting closer and closer to the point where i could finally write and maintain my own packages (clarification: sorry, not my “own”-own, the ones that i like! that are not mine… but the ones that i turned into a nixpkg to share with the community?)… lots of cool stuff that i find that is not in nixpkgs or flakes… and i am trying more and new things! each one more difficult than another! and i like interacting with this community, asking my silly little questions. it is nice!

oh and… after 4 months, i only now realise and understand some of the explainers by TLATER (no ping), that i didnt before… it makes much more sense now…

thank youu and sorry once again…

waffle8946 · September 4, 2025, 7:40pm

Slightly OT but flakes (which use fetchTree), npins (which use builtin fetchers), and builtin fetchers are AFAIK not derivations. They are worse - they download during eval instead of during build, which means they download serially instead of in parallel.

Ironically, with a large number of external inputs, IFD is probably better than import-from-builtin-fetcher due to parallelization and laziness (and nvfetcher uses nixpkgs fetchers which are really derivations).

Specify the commit or tag in the url for that input.

Don’t specify the commit or tag in the url for that input. The “random numbers” are the commit hash.

You still need to run nix flake update explicitly though, as that’s the whole point of having a lockfile…

This requires learning git (and github for the PR aspect).

I’ve never seen this behavior; there’s no reason you need to build a windows target if you’re just using Linux. Provide a specific example if you need help.

frozen.frog23 · September 4, 2025, 8:24pm

sorry, i think i dont understand… like so?

github:OWNER/REPO/3.00

or

github:OWNER/REPO/PKG-3.00

or

github:OWNER/REPO?ref=v3.0.0

okay! hahaha sorry for calling them “random numbers”, bit you know what i mean!

oh… uhm… well, i dont want to either! but it just does whatever it wants, really. for example, okay, i had to compile a valve steam deck kernel every time there is an update… for every platform, architecture and hardware from THIS flake, which ive talked about already a few posts ago:

  jovian-nixos.url = "github:jovian-experiments/jovian-nixos"; # https://github.com/Jovian-Experiments/Jovian-NixOS

what should i do in a situation when a flake does this? it takes up to 3-4 hours! i believe its only the kernel that is from the flake taking this much time. so, perhaps, ANY flake with a kernel?

thanks!!!

and as for rust… oh, sorry, i forgot to look for one, one moment please…

okay… MAYBE i am mistaken? i clearly remember flakes with rust applications…

  caracal.url = "github:xrelkd/caracal"; # tui -- https://github.com/xrelkd/caracal
  yazi.url = "github:sxyazi/yazi"; # tui -- https://github.com/sxyazi/yazi
  anyrun.url = "github:anyrun-org/anyrun"; # gui -- https://github.com/anyrun-org/anyrun

(example, i dont use these)

…compiling for i686 and aarch64 and so on… but ive since then removed all of those inputs because of it… however! when i just tried readding them again, they instantly just downloaded. no compilation whatsoever! mad. but it cant be, if i used the garbage collector ages ago? (a few months ago, not to say that i wasnt using it since then, no, quite often, actually)

please, never mind this, i might be too confused to understand, sorry

edit: to clarify, rust applications WITHOUT cachix

TLATER · September 4, 2025, 10:01pm

Yeah, this should not be happening, unless you ask nix to do it somehow. I can’t even fathom how you would, given lazy evaluation.

Can you tell us exactly what commands you’re running to cause that, and what your configuration looks like? I think maybe you could cause this with nix flake check and some specific arguments, but it should not run the checks of your inputs.

frozen.frog23:

waffle8946:

Specify the commit or tag in the url for that input.

sorry, i think i dont understand… like so?
github:OWNER/REPO/3.00
or
github:OWNER/REPO/PKG-3.00
or
github:OWNER/REPO?ref=v3.0.0

Yes.

Well, kind of. All of these are valid ways to specify a ref, but they all specify different refs, and which ref works for a given repository depends on the repository. They may all be valid in practice (and all mean different things), or none of them could be valid.

Your question ultimately boils down to “how does git work” and “how do flake URIs express git revisions”. If you don’t understand the former, it’s pretty impossible to explain the latter.

Nix flakes don’t have a way to express a version. As such, there is no syntax to upgrade/downgrade flakes according to version numbers or anything of the sort.

Nix flakes do support git inputs, and there is syntax for specifying specific commits, or tracking specific branches. Git is a version control tool, so this kinda gives flakes “versioning” through the backdoor.

People use this to provide an actual API for version selection in practice. They set up branches in their repositories which you can point nix at, and if the branches are maintained sensibly this makes for something like what you want. It also means that it entirely depends on the branching scheme of the projects you depend on whether and how this works, though, so generally you’ll have to read documentation and/or understand git and how a specific project uses it to be able to do the things you want to do.

You can look at the examples from the manual to get an intuition for how the URLs work. But you’ll have to separately learn what “branch”, “tag”, “ref” and “rev” mean in the git world.

Note by the way that git != github. Git is a FOSS version control tool initially written by Linus Torvalds himself, github is a completely unaffiliated, proprietary website that hosts repositories and has a nice UI for browsing them (and has some social media features unrelated to git, PRs and issues and such). The latter type of software is referrred to as a “git forge” these days, named after sourceforge which was the first website to offer this kind of centralized source hosting (sourceforge in turn predates git, but also offers git forge functionality nowadays).

Learning git is well worth it. I’d suggest at least figuring out how branches, tags and commits work.

If you want to host your code on a git forge (which is by no means necessary, but helpful when you ask for help since it makes it easier to show what you’re doing), I’d suggest https://codeberg.org/ these days. Github is far along on its enshittification journey.