chore: split default.nix and main.nix

[MattSturgeon]

Followup to #401 where I noticed that nix flake show requires IFD.

This PR delays merging the default package into the top-level default attrset, and avoids needing to evaluate the actual package (currently using IFD) in order to compute flake outputs.

This fixes nix flake show when allow-import-from-derivation is false.

The previous behaviour (nix-build without arguments building the default package and nix-build -A having access to specific attributes) is retained.

[github-actions]

Nixpkgs diff processing..

Will be available here

[jfly]

LGTM, although this will cause conflicts with my upgrade PR :( That's fine, I can rebase.

I feel like I've seen ci.nix or release.nix as alternate names for this main.nix file, if you were searching for something idiomatic. No big deal either way.

Have you confirmed that the attrset returned by default.nix is an exact match (or superset) of the attrset previously returned? I haven't read the code carefully enough to confirm.

[jfly]

This smells a little odd to me. Why not do args: ...? Are you trying to preserve the old behavior of not accepting any other keys? Could use a brief comment if that's why.

[MattSturgeon]

It's a bit ugly, but it is a pretty common pattern in nix.

Here, we use it for a few orthoganal reasons.

The main reason we use it here is that nix-build (etc) can fill in named set-pattern arguments, which is why nix-build or nix-instantiate without arguments can evaluate the existing default.nix before this PR.

We could also solve that by not taking an args at all (like in shell.nix), but that breaks the other useages; supplying --arg or --argstr to nix-build or importing the file and calling it with a {} argument.

I'll add a comment.

[MattSturgeon]

Added

Mirror main.nix's function arguments for nix-command --arg support

to default.nix and

NOTE: update mirrored args in default.nix when modifying

to main.nix.

[MattSturgeon]

I feel like I've seen ci.nix or release.nix as alternate names for this main.nix file, if you were searching for something idiomatic. No big deal either way.

I wouldn't choose ci.nix, because this is unrelated to CI. I could see an argument for release.nix, as these are our "public" entrypoints. I feel like main.nix also expresses that well, without conflating it with tagged-releases?

I see main.nix as the central semi-internal/semi-public orchestration point of our public outputs, used by flake.nix, default.nix, shell.nix, and internal scripts.

[MattSturgeon]

I split up the commit history a bit more, so when rebasing or blaming git will now recognize default.nix -> main.nix as a rename. This should mean most conflicts can be resolved automatically.

[MattSturgeon]

@jfly the nixpkgs-diff CI failure is expected here, because it runs from the default-branch's context and the this PR's changes to scripts/sync-pr-support.nix don't affect it.

That means the one commit where default.nix is removed fails to evaluate, leading to the CI failure.

I laid out the commits that way intentionally, so that git recognises the "old" default.nix was renamed to main.nix and then the next commit introduces a "new" default.nix.

If we want to merge this with the sane git history, you'll need to bypass the rulesets and force-merge (as repo admin).

Incidentally, any other PRs based on a revision that doesn't have a main.nix will also fail nixpkgs-diff once this merges; at least, until they rebase. Because the default branch will at that point be trying to import main.nix.