Module system tweaks#2540
Closed
shlevy wants to merge 13 commits into
Closed
Conversation
Member
Author
|
cc @edolstra |
Member
Author
|
^ latest commit notes an issue that exists on master too with the |
Member
Author
|
^ And this latest fixes that issue. |
shlevy
added a commit
to shlevy/nixops
that referenced
this pull request
May 14, 2014
With the --modular-expressions flag, nixops will now treat the expressions as a module, with machines and resources being evaluated as submodules. This allows defining deployment-level options/configuration, as well as reducing duplication between eval-machine-info.nix and eval-config.nix. Machines are now defined as attributes in resources.machines, and the network.* configuration are now in the top-level config namespace (so there's an enableRollback option, a description option, etc.). For convenience, the top-level configuration can be accessed as the 'deployment' argument to each module. Depends on NixOS/nixpkgs#2540 (though deployments without the --modular-expressions flag will work without it). Fixes NixOS#78 (see issue for more details on motivation).
Member
|
👍 |
shlevy
added a commit
to shlevy/nixops
that referenced
this pull request
May 20, 2014
With the --modular-expressions flag, nixops will now treat the expressions as a module, with machines and resources being evaluated as submodules. This allows defining deployment-level options/configuration, as well as reducing duplication between eval-machine-info.nix and eval-config.nix. Machines are now defined as attributes in resources.machines, and the network.* configuration are now in the top-level config namespace (so there's an enableRollback option, a description option, etc.). For convenience, the top-level configuration can be accessed as the 'deployment' argument to each module. Depends on NixOS/nixpkgs#2540 (though deployments without the --modular-expressions flag will work without it). Fixes NixOS#78 (see issue for more details on motivation).
Member
Author
|
Rebased |
Member
Author
|
@edolstra @rbvermaa I've rebased this again. Is there anything stopping us from merging? It is blocking NixOS/nixops#187 from being useful |
Member
|
@edolstra, @rbvermaa: I'd like to know as well what's the blocker against merging this, especially because I have several deployments that would benefit from NixOS/nixops#187 as well. |
Member
|
The NixOS module system is too much magic for me to judge if it can be merged, so I won't merge. @edolstra ? |
Member
There was a problem hiding this comment.
This is incorrect - IIRC, amazon-config.nix is copied to /etc/nixos/configuration.nix, so it cannot use ./amazon-image.nix. But probably it can use <nixpkgs/nixos/modules/...>.
Member
|
Could you push all those |
This makes the relationship between property types clearer, and more importantly will let option types parameterized by other option types reuse the code for delegated type checking and merging.
This simplifies typechecking and allows properties to be used inside the lists
This simplifes typechecking and allows properties to be used inside of the attribute sets. This fixes the empty synergy-client and synergy-server services previously generated on systems with synergy disabled.
This symplifies typechecking and allows properties to be used inside the function body. It also makes possible checking the type of the result.
This allows for module arguments to be handled modularly, in particular allowing the nixpkgs module to handle the nixpkgs import internally. This creates the __internal option namespace, which should only be added to by the module system itself.
Ideally the module system could be configured pretty much completely by the contents of the modules themselves, so add comments about avoiding complicating it further and possibly removing now-redundant configurability from the existing interface.
Member
Author
|
Addressed both comments. |
shlevy
added a commit
to shlevy/nixops
that referenced
this pull request
Jul 8, 2014
With the --modular-expressions flag, nixops will now treat the expressions as a module, with machines and resources being evaluated as submodules. This allows defining deployment-level options/configuration, as well as reducing duplication between eval-machine-info.nix and eval-config.nix. Machines are now defined as attributes in resources.machines, and the network.* configuration are now in the top-level config namespace (so there's an enableRollback option, a description option, etc.). For convenience, the top-level configuration can be accessed as the 'deployment' argument to each module. Depends on NixOS/nixpkgs#2540 (though deployments without the --modular-expressions flag will work without it). Fixes NixOS#78 (see issue for more details on motivation).
Member
Author
|
Closing as this doesn't seem wanted. |
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
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
5 participants
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 branch includes some improvements to the module system, which are of general interest I believe but will also make my forthcoming work on NixOS/nixops#78 cleaner. There are two fundamental user-visible changes here:
mkIfinside of an option that is a container. So if you have an optionfoothat istypes.attrsOf types.int, you can now havefoo.bar = mkIf cfg.useBar 2;for example. Note that currently all post-systemd nixos setups have an emptysynergy-client.serviceandsynergy-server.servicedue to this not working as expected on master.pkgs,modulesPath, etc. that is currently passed everywhere in nixos) and the configuration knob to determine whether or not to allow definitions of options that aren't yet declared are now governed by internal options (__internal.argsand__internal.check). The current interfaces in<nixpkgs/nixos/lib/eval-config.nix>/evalModulesstill work, but they use this under the hood. This makes the set of modules plus the version of<nixpkgs/lib>a full specification of the configuration, which is especially helpful in cases (like NixOS containers or modular nixops) where we want to make one config a submodule of a larger setup.This introduces one backwards-incompatibility: Due to the change in how arguments are handled, modules shouldn't use the
pkgsargument to get access to the module functions (mkOption,mkIf,types, etc) inpkgs.lib. Instead, they should use thelibargument that is passed to all modules, or they may result in an infinite recursion. This is already fixed for all in-tree modules, and unless you define options your personal configurations will probably not need to change, but if you run into an infinite recursion this is why, and the fix is to switchpkgs.libto justlib.