-
Notifications
You must be signed in to change notification settings - Fork 3
New features, better error messages #7
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.
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
Closed
Closed
Conversation
This file contains hidden or 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.
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.