You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Currently we expose a few "system module" wrappers for nixvim, specifically for nixos, home-manager, and nix-darwin.
We plan to promote the use of an evaluated nixvim config to access a "standalone build" of nixvim (#2210). I believe we can do something similar with the wrapper modules to.
Ideally, I would like to expose wrapper modules as "deferred module" type options in the nixvim configuration. You would then access them as <nixvim>.config.modules.homeManager for example. However, I'm not sure this is possible, because the wrapper module would need access to <nixvim>.extendModules on the fully evaluated nixvim configuration.
As an alternative, we could provide functions alongside evalNixvim, such as toHomeModule, toNixOSModule, toDarwinModule, and a more generic toSystemModule. These functions would take a nixvim configuration as input and return a system module as output.
The existing modules could make use of these functions, supplying an empty nixvim configuration as input.
Along with a nixvim configuration, we could also have additional arguments:
toSystemModule={# name to use in `programs.<name>`,# or a list to specify the whole option pathname ? "nixvim",# modules to import at the system level# e.g. `toNixOSModule` would add modules to this listsystemModules ? [],# modules to import at the nixvim level# e.g. We might use this to add an `enable` optionnixvimModules ? [],# nixvim configuration to extendnixvimConfig ? evalNixvim{},# extra specialArgs to add/override nixvim configuration'sextraSpecialArgs ? {},}:
letprefix=ifbuiltins.isListnamethennameelse[
"programs"
name];finalConfig=nixvimConfig.extendModules{inheritprefix;modules=nixvimModules;specialArgs=extraSpecialArgs;};in# Return a module{lib,config, ... }:
{_file=./.;imports=systemModules;options=lib.setAttrByPathprefix(lib.mkOption{inherit(finalConfig)type;default={};description="Nixvim config";});}
Currently we expose a few "system module" wrappers for nixvim, specifically for nixos, home-manager, and nix-darwin.
We plan to promote the use of an evaluated nixvim config to access a "standalone build" of nixvim (#2210). I believe we can do something similar with the wrapper modules to.
Ideally, I would like to expose wrapper modules as "deferred module" type options in the nixvim configuration. You would then access them as
<nixvim>.config.modules.homeManager
for example. However, I'm not sure this is possible, because the wrapper module would need access to<nixvim>.extendModules
on the fully evaluated nixvim configuration.As an alternative, we could provide functions alongside
evalNixvim
, such astoHomeModule
,toNixOSModule
,toDarwinModule
, and a more generictoSystemModule
. These functions would take a nixvim configuration as input and return a system module as output.The existing modules could make use of these functions, supplying an empty nixvim configuration as input.
Along with a nixvim configuration, we could also have additional arguments:
Related issues:
nixvimConfig
) #2210The text was updated successfully, but these errors were encountered: