Skip to content

Conversation

Noah765
Copy link

@Noah765 Noah765 commented Jul 14, 2024

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.

Noah765 added 12 commits July 14, 2024 10:32
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.
Noah765 added 5 commits July 15, 2024 09:44
…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.
@Noah765 Noah765 closed this Jul 15, 2024
@Noah765 Noah765 deleted the organised branch July 15, 2024 10:05
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

1 participant