And flakes are just an agreed upon set of outputs (i.e. packages.${system} or nixosConfigurations), and a way to explicitly say where you are importing your nix channel from, as well as defining a way of importing things slightly nicer than fetch functions while still making sure everything is locked appropriately and still updatable either atomically or all at once.
They have inputs and outputs, (outputs is a function that recieves the things in inputs and a self variable and returns outputs of the agreed upon format) and a description.
The format is what allows the nicer command line syntax, because the cli has targets it can now look for.
The inputs are what allows for the lockfile, as now it knows what to put in the lockfile
The fetch functions are already locked because you need to put the hash. So those are locked by default, and not being in inputs is not an issue. anything fetched from the channel is locked to the version of the channel in the lockfile because thats the version of the channel you imported.
This makes importing from multiple channels very easy, and makes synchronizing your channels between machines, as well as between nixos and home manager, much easier, as now they are in the lock file and do not need to be configured via external commands.
Right now I have one flake.nix under /etc/nixos/. I created it based on this example from @tobiasBora.
Do I understand it correctly that every program I install should have its own folder with its own flake? For example, when I searched for vscodium flake I found the vsc flake.nix.
UPDATE:
I believe I should read this first, as it looks like my question might be answered there.
you should organize most things via modules. flake is a top level thing. You would include modules in a nixosConfiguration and then output the nixos configuration from the top level flake. You can export packages and modules from your flake to be used by other flakes as well although all you need for nixos is a nixosConfiguration
Flakes are general, they can be used to create a nix package separate from nixpkgs, and their outputs can be imported via cli commands and other flakes, and they can also output entire system or home manager configurations. They can also output anything else you want, but there is a set of agreed upon ones for cli commands
They are more or less a wrapper for the normal module system to keep your overall outputs and inputs organized and locked rather than to be a primary method of organizing your setup internally.
You should only have a new flake if you want an entirely new project, as it will need to be its own git repo or git submodule
I agree with what have been said above. Just to complete:
Most of the time, you can just use nixpkgs (that you can imagine as a huge flake containing thousands of apps), simply adding stuff to your configuration.nix, like in environment.systemPackages, and even forget that you are using flake under the hood. If for some reasons this is not enough (e.g. you want to use something that is not packaged in nixpkgs but is packaged in an external flake), then sure you can add it to your own flake.nix. But for vscode, you certainly don’t need a flake, you can simply use vscode for nixpkgs NixOS Search (if you want to install extensions, see also Visual Studio Code - NixOS Wiki)
You cant really declare a new flake without declaring a new git repo so its generally the way to go yeah. You can do something like subflakes by just putting the output section of the flake in a file and importing it as an expression and passing it the inputs and self from the main flake? Because at the end of the day outputs is just a function? You can also make git submodules? but yeah generally people just have 1 flake and organize the rest via modules and stuff.