Rename `defaultX` flake outputs to `X.default`

[edolstra]

We have a couple of flake outputs that have a corresponding "default" flake output, e.g.

• packages and defaultPackage
• devShells and devShell
• apps and defaultApp
• overlays and overlay
• nixosModules and nixosModule
• templates and defaultTemplate
• bundlers and defaultBundler

There are also some flake outputs that lack a default, but could probably use one, like nixosConfigurations.

As can be seen above, the naming is inconsistent. It also requires a lot of special handling in commands like nix flake show and nix flake check. So I propose getting rid of all the singular flake outputs and using an attribute named default as the default. E.g.

• defaultPackage.<system> => packages.<system>.default
• devShell.<system> => devShells.<system>.default
• overlay => overlays.default

Migration: we can deprecate the old singular flake outputs in 2.5 and remove support for them some time later.

[thufschmitt]

One issue with this is that we’ll then have a default in the same namespace as the rest, which isn’t very clean.
Like if I want something that iterates over all the packages exported by a flake (or my flake has hydraJobs = self.packages), then there will be a default package that’s probably just a duplicate of another one and doesn’t really make sense.

Also, if I want to reuse the outputs of flake as an overlay (do something like import nixpkgs { overlays = [ (_: prev: nix.packages.${prev.system}) ]; }, then I’ll also add a default package.

(not that these are really blockers of course, but it’s mildly annoying)

[michaelpj]

Having suffered through lots of annoyance due to working with some nix code that mixes derivations with different meanings together: please keep collections homogeneous! Put the special attributes somewhere else.

[hazelweakly]

This brings up a slightly unrelated point of annoyance for me. There's a solid amount of flake attributes that are system namespaced as well as ones that are not system namespaced. The separation prevents things like cleanly writing a forAllSystems {} flake generator (you end up with forAllSystems {} // { the rest of the flake} or, worse, forAllSystems {} // ( if arm mac then {}) // (if x86_64 linux then {}) // ...

To reiterate on @michaelpj's point, one of the big appeals behind flakes (for me) was that:

• purity meant you could actually cache stuff
• defined outputs and structure meant that you didn't need to stick magic inside attributes that needed to be evaluated. The last bit makes things really slow occasionally, and is errorprone as anyone who has ever touched nixpkgs's python stuff can attest to.

If attributes are going to be modified for consistency, I think a standardized naming scheme and attribute shape makes more sense; but I think we should strongly avoid any situation in which <thing>.default can be ambiguous.

[thufschmitt]

Random suggestion: What about giving each flake a canonical name (with a name field for example), and using this name as the default attr name?
For example nix build would first try packages.${builtins.currenSystem}.${name}.

That way there’s no need for a distinguished defaultXXX field, and we also don’t have the duplicate default field since it will generally make sense to have the default package named like the flake

[tomberek]

Beginning to implement: tomberek@28c2db5

Random notes

Notes about using "name":

nixosConfigurations vs nixosConfigurations.HOSTNAME - special, need "hostname"

• needs more thought.... HOSTNAME -> name -> "default" -> error

what if "name" is not defined? use "default" with warning to please add a name

mismatch between flakeref's name and flake name attribute:
nix flake show
github:org/some-name and { name = "something";}
path - doesn't have a name
. - doesn't have a name

todo: add to nix flake show

• add to self.name and to lockfile
• add to self.description and to lockfile

Adding name will cause eval breakages.

• add the capability, don't use it for now... slowly adopt as people go to 2.5/6/7/8.
• hard error in 2.4