Flakes
Some software is not in nixpkgs and never will be. A Neovim distribution, a
shell framework, a work module on a private GitHub — these ship their own
flake, and installing one is not adding a package. It is declaring an
input, which means editing flake.nix: the one file this plugin otherwise
never touches.
The sixth tab does that.
Looking before you leap
Type a flakeref into the field — github:owner/repo — and press RETURN.
Nothing is written. nix flake show needs no build, and this step exists
precisely so you can look at what you are about to run somebody else’s build
code for. It takes about a second on a local flake and ten on a first remote
fetch.
What comes back is a list of what the flake exposes:
· github:nix-community/nixvim
· nixosModules.default
· nixosModules.nixvim
· 7 packages
· homeManagerModules — exists, contents cannot be read
· homeModules — exists, contents cannot be read
· declare this as an input
“contents cannot be read” is not “empty”
Those two lines are the honest part, and they are worth explaining because they look like a failure and are not.
nix flake show understands nixosModules: it comes back typed and
enumerated, which is why you can see both default and nixvim above.
Every other module namespace — homeManagerModules, homeModules,
darwinModules, nixDarwinModules, flakeModules, modules — is a
community convention rather than anything Nix has a schema for, and flake
show returns them as a single opaque value.
So the panel can tell you the namespace exists and nothing about what is in it. It says exactly that, rather than drawing an empty list — because “this flake offers none” and “I cannot tell” are different statements and only one of them is true.
Declaring it
RETURN on declare this as an input, and it asks what to call it. The
field is filled with a suggestion taken from the repository, not from the
end of the ref: github:nix-community/home-manager/release-25.05 suggests
home-manager, never release-2505. RETURN takes it, typing replaces it,
and ESC goes back to what the flake offers. A name is letters, digits, _
and -, starting with a letter or _; anything else is refused before the
file is touched. So is a flakeref with a quote, a backslash, a $, a
backtick or a space in it — no real one has any, and in the file they would
be Nix rather than data.
One line is then appended to your flake.nix:
inputs.nixvim.url = "github:nix-community/nixvim"; #@flake-input nixvim
Your own inputs { } block is not touched. It does not need to be: in Nix, a
path assignment merges with an attrset that already exists, so the line is
appended at the top level and Nix does the joining. That is why this can edit
the most important file on your machine without reformatting a single line
you wrote.
Then it locks it, and checks:
- the flake already evaluated before the write — if it did not, nothing is written and you are told the flake was broken already, rather than having this blamed on whatever was added last
- the file still parses
nix flake lockresolves the input- the flake still evaluates
Any failure at 2, 3 or 4 puts both flake.nix and flake.lock back
exactly as they were, and reports nix’s own words rather than a guess at them.
What it does not do is build a host. An input that nothing imports cannot break one, and evaluating a host costs minutes to prove more than is at stake.
The part it will not do for you
It shows you the import line:
inputs.nixvim.nixosModules.default
and tells you, plainly, that it does not know which file that belongs in.
That is deliberate and it is the main design decision in this feature.
default is a good guess at which module — across nixvim,
home-manager and sops-nix the convention is always default beside a
named alias — but knowing the attribute settles one choice out of four.
Which host wants it, whether the module takes arguments, and whether
an option must be set to enable it are all still open, and the panel
cannot even name the host file: it derives a directory from your hostname,
which is neither a nixosConfigurations attribute nor an import site.
Writing a plausible guess into your configuration would be worse than writing nothing, because a bad line there fails the evaluation of your whole system rather than one package. So it hands you the line and says what it does not know.
Two refusals
A name your flake already uses. Two definitions of one input is an error, so it is refused outright and nothing is written.
Removing an input something still depends on. If another input follows
it, or the name appears anywhere else in your flake — an import you pasted, a
specialArgs reference, a host module in another .nix file that uses
inputs.<name> — removal declines and names the file and line. Succeeding
would break evaluation, which is the one thing this must never do quietly.
It errs on the side of refusing. It matches the name as a whole identifier
(sub-projects is not sub), but a mention in a string or a comment still
counts. If the file and line it names are only a mention, remove the input
by hand. And it checks the flake evaluated before removing anything, so
a flake that was already broken is not blamed on the removal. What a removal
that succeeds proves: the flake still parses, locks and evaluates its
metadata. It does not evaluate every host.
One warning, which is not a refusal
If you pick a name that nixarchy also uses — nixpkgs, home-manager,
sops-nix and about fourteen others — you get a warning rather than a
refusal, and the distinction is measured rather than cautious.
On a machine installed from the nixarchy ISO, the generated flake hands its
modules self.inputs // nixarchy.inputs. That merge is right-biased, so a
colliding name locks perfectly and is then silently ignored by every
module. On a flake you wrote yourself and added nixarchy to, the inputs
usually pass straight through and nothing is shadowed at all.
Since the second is most people, refusing everyone would block a legitimate
name to prevent a hazard their machine does not have. So it tells you the
condition and lets you decide. The list of taken names is read from your
flake.lock rather than hard-coded — a hand-written list was already wrong
about nixpkgs, the name you are most likely to reach for.
From a terminal
nixarchy-pkg flake show github:nix-community/nixvim
nixarchy-pkg flake add nixvim github:nix-community/nixvim
nixarchy-pkg flake list
nixarchy-pkg flake remove nixvim
Same commands, same output. See From a terminal.
What this is not
A package manager for flakes. It declares an input and hands you back the wiring, which is the half a tool can do safely. How it works explains the general version of that boundary.