New features, better error messages #8
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
I only modified the unifyModuleSyntax function, but had to copy additional functions that aren't exported by nixpkgs without warning.
Problems: - When specifying the same input in both flake.nix's initialInputs and in a module, initialInputs would silently override the module's inputs. - The error messages when specifying the wrong input type or adding an input twice weren't very helpful because they didn't show the path to the invalid or duplicate inputs. Background: Nix gets the path to a flake input for error messages from it's definition location within the inputs attrset, which makes it impossible to use the module system and get good error messages. Adding inputs twice but with different definition values, or making a typo when adding an input, will now result in good error messages with paths to the relevant places in the code. To allow adding inputs within the config section of a combined manager module if the input is protected by an mkIf whose condition depends on the code the input adds, mkIfs, mkOverrides and mkMerges are now ignored.
It is not currently necessary to add nixpkgs and home manager in initialInputs, they can be added elsewhere.
osModules is now an alias for osImports and hmModules is an alias for hmImports. The unifyModuleSyntax now handles top-level osImports and hmImports as if they were config.osImports and config.hmImports.
Not using evalModules to evaluate osImports is necessary for copying option declarations from modules imported in osImports, since the osImports (or osModules) definition could be guarded by the same declaration that depends on the import. Also, having consistent behaviour between inputs, osImports and hmImports leads to less unexpected results.
The main entry point of a program is the first place people interested in the project, who want to see how it is implemented or add some features, go, and therefore a good place to present them with an overview of the public interface, as well as the places to look for further implementation details. I have cleaned up default.nix to make it as readable as possible, split the project into more self-contained parts and made each of them more readable.
- specialArgs are now also being passed to NixOS and Home Manager modules - The combinedManager specialArg now refers to the evaluated root of Combined Manager, and not it's path. The path is available under combinedManagerPath. - useHm is now being provided to enable conditional logic based on whether Home Manager is currently enabled.
Global specialArgs, modules, a default system and a default useHomeManager option are now provided.
These args make it trivial to copy any option declared in other NixOS or Home Manager modules.
…me Manager modules I think it makes sense to treat them like most other specialArgs like inputs, useHm and configs, because they are just simple static values.
- Two additional sections have been added to the README. - Hashes are no longer hardcoded, as it's not feasible to update them every time a change is committed. - The welcome text for the templates is now much shorter, to give users a better experience when creating templates.
This is the version used by nix-dram.
The function mergeModules' requires these functions.
The description of what is currently possible with the module system and how `osOptions` and `hmOptions` enable more advanced use cases is now more clearly described. The bad example has also been removed.
This makes it possible to define these options even when Home Manager is diabled, although they will then have no effect, making it much easier to share modules between configs that enable or disable Home Manager.
…en using the osOptions or hmOptions args
This is useful for evaluating Combined Manager options with `nix eval`.
These attributes are needed by some applications, e.g. `disko-install`. When using `lib.nixosSystem`, they are defined here: https://github.com/NixOS/nixpkgs/blob/d51dad7c7766199c8ad12a317315b0bd6f53459c/nixos/lib/eval-config.nix#L110-L115
These options aren't currently used and are safe to remove.
`nixos-install` copies the config and all flake inputs to `/mnt/nix/store` by default, but when run from within the installer, the `outPath` of the input derivations still points to their original location within `/nix/store`, not `/mnt/nix/store`. The nixpkgs documentation module relies on `modulesPath` having the same prefix as its file location, which is not the case here. This commit provides a workaround for this problem by not relying on the `outPath` of flake inputs for the `modulesPath` os arg.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This is a follow-up PR to #6, because my commits were a total mess. I have tried to re-commit my changes in an organised way to make the PR easier to review.