foodogsquared/nixos-config
1
0
Fork 0
mirror of https://github.com/foo-dogsquared/nixos-config.git synced 2025-01-31 10:58:02 +00:00
Code Issues Actions 1 Packages Projects Releases Wiki Activity

wrapper-manager-fds/docs: update project overview and add design notes to modules

Browse Source
This commit is contained in:
Gabriel Arazas 2024-08-03 16:47:08 +08:00
parent f88190bc18
commit fcd9503664
No known key found for this signature in database
GPG Key ID: 62104B43D00AA360
2 changed files with 20 additions and 8 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

16
subprojects/wrapper-manager-fds/docs/website/content/en/project-overview.adoc
View File

@ -38,7 +38,7 @@ nix-channel --add {remote-git-repo}/archive/master.tar.gz wrapper-manager-fds
nix-channel --update nix-channel --update
---- ----
Then in your environment configuration, you'll have to import it. Then in your environment configuration, you'll have to import the user entrypoint.
For more details, see <<user-entrypoint>>. For more details, see <<user-entrypoint>>.
[#installation-pinning-tool] [#installation-pinning-tool]
@ -65,9 +65,9 @@ Though not recommended, you could manually pin the Nix library yourself like in
{ pkgs, ... }: { pkgs, ... }:
let let
wrapper-manager-fds = builtins.fetchTarball "{remote-git-repo}/archive/master.tar.gz"; wrapper-manager-fds-src = builtins.fetchTarball "{remote-git-repo}/archive/master.tar.gz";
wrapperManager = import wrapper-manager-fds { }; wrapper-manager = import wrapper-manager-fds-src { };
wrapperManagerLib = import wrapperManagerLib.lib { inherit pkgs; } wrapperManagerLib = import wrapper-manager.wrapperManagerLib { inherit pkgs; }
in in
wrapperManagerLib.env.build { } wrapperManagerLib.env.build { }
---- ----
@ -119,11 +119,11 @@ To use it, it only requires a nixpkgs instance like in the following code.
{ pkgs, ... }: { pkgs, ... }:
let let
wrapper-manager-fds = builtins.fetchTarball "{remote-git-repo}/archive/master.tar.gz"; wrapper-manager-fds-src = builtins.fetchTarball "{remote-git-repo}/archive/master.tar.gz";
wrapperManager = import wrapper-manager-fds { }; wrapper-manager = import wrapper-manager-fds-src { };
wrapperManagerLib = import wrapperManagerLib.lib { inherit pkgs; } wrapperManagerLib = import wrapper-manager.wrapperManagerLib { inherit pkgs; }
in in
wmLib.env.build { } wrapperManagerLib.env.build { }
---- ----

12
subprojects/wrapper-manager-fds/modules/wrapper-manager/README.adoc
View File

@ -3,3 +3,15 @@
This is the module set of the wrapper-manager module environment. This is the module set of the wrapper-manager module environment.
Just take note that we're following the runtime shell of nixpkgs which is GNU Bash as of 2024-06-30. Just take note that we're following the runtime shell of nixpkgs which is GNU Bash as of 2024-06-30.
Also, take note of several design decisions when making the modules.
* Typically, several options are designed around one option.
The most prominent example of this is `wrappers.<name>.makeWrapperArgs` where we basically create those `makeWrapper` arguments from other options.
* Another common design here is most of the interaction happens around in individual wrappers so individual-wrapper-wide options are typically accompanied with a environment-wide version of that option.
An example of that is `environment.variables` and `environment.pathAdd` where it's basically a global set/list of variables and search paths to be put in each wrapper (that is, `wrappers.<name>.env` and `wrappers.<name>.pathAdd`).
* When constructing modules with a `listOf <type>` that is going to be set some other options, typically it is better to have them set in the individual wrapper and nothing else.
An example of that can be seen in `xdg.dataDirs` and `wrappers.<name>.xdg.dataDirs` implementation.
This is designed like that so the user can override the entire thing if they choose.