Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

flake check: Ignore more attributes + doc #8332

Open
wants to merge 1 commit into
base: master
Choose a base branch
from
Open

flake check: Ignore more attributes + doc #8332

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
34 changes: 34 additions & 0 deletions src/nix/flake-check.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -70,4 +70,38 @@ Hydra's `hydra-eval-jobs` (i.e. as a arbitrarily deeply nested
attribute set of derivations). Similarly, the
`legacyPackages`.*system* output is evaluated like `nix-env -qa`.

# Unchecked attributes

Some attributes do not come with checks but are permitted by `nix flake check`;
they do not cause a warning.

- `lib`: a Nix-language library containing functions and perhaps also constants.
No convention has been established for `lib`, so its value is not checked.

- `debug`: Anything that the flake author deems useful for troubleshooting the flake.

- `internals`: Anything that the flake needs for its own purposes, such as attributes that support developer tooling.
Consumers of a flake should avoid this attribute, as its author should feel free to alter its contents to their needs.

A number of well known module system applications' attributes is also ignored.
Configuration values have gained a `_type` tag since NixOS 23.05 and may be checked in the future.
Modules have such a flexible syntax that checking them is barely worthwhile. For now, `nix flake check` does not check them, so that these attributes' interpretation is up to the module system and its applications. Limited checks might be added later.

- `darwinConfigurations`
- `darwinModules`
- `flakeModule`
- `flakeModules`
- `homeConfigurations`
- `nixopsConfigurations`

`nix flake check` also allows for general purpose module system attributes. Module system applications should pick a [*class*](https://nixos.org/manual/nixpkgs/unstable/index.html#module-system-lib-evalModules-param-class) to separate their own modules and configurations from other applications. The subattribute structure below may be subject to change.

- `modules.`*class*`.`*moduleName*: Modules that are compatible with a specific module system application.
- `modules.generic.`*moduleName*: Generic modules that are not tied to an application.
- `configurations.`*class*`.`*name*: Concrete configurations. These tend to correspond to single real world objects, or sometimes classes of objects where the same configuration applies.

Some third party attributes are also ignored.

- `herculesCI`

)""
4 changes: 4 additions & 0 deletions src/nix/flake.cc
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -658,12 +658,16 @@ struct CmdFlakeCheck : FlakeCommand

else if (
name == "lib"
|| name == "configurations"
|| name == "darwinConfigurations"
|| name == "darwinModules"
|| name == "debug"
|| name == "flakeModule"
|| name == "flakeModules"
|| name == "herculesCI"
|| name == "homeConfigurations"
|| name == "internals"
|| name == "modules"
|| name == "nixopsConfigurations"
Comment on lines 660 to 671
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hold on guys, are we now adding not only nixpkgs specific code to nix but also random flakes specific code? 👎

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

configurations and modules are for #6257. I don't suppose those are a problem?

Do you mean debug and internals? I think ignoring those is useful for any flake that wants to be easy to troubleshoot.

These changes are quite intentional and not random or specific to any flake?

If you mean that we shouldn't add code specific to the flakes feature, I can agree with that. It would be nice to separate that out, but I don't think that's a particularly productive choice of component to spin off. I'd rather do that with the dev shell logic, a component whose independent development would pay off more, and where it would make sense to have pinnable or alternate implementations.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sorry, I meant the old ones.
configurations and modules are fine but don't solve anything
instead of internals and debug maybe it would be nice to keep a single attribute since both of them generally are going to be used for the same thing

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I like the separation. For instance, internals could be used in a shebang script, whereas debug is only for human consumption and therefore can be assumed that messing around with it is ok.
Using debug from a shebang script seems like a bad idea, but debugging using internals isn't quite as bad. I suppose internals.debug could be a convention, but the indirection is unnecessary and a bit annoying when you're using it in the repl. So internals is definitely the one to keep, but debug is also worth the tiny cost.

)
// Known but unchecked community attribute
Expand Down