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

docs: update modules design guidelines

Browse Source
This commit is contained in:
Gabriel Arazas 2024-01-20 11:29:33 +08:00
parent 2a9d435e8d
commit 5acba7ba41
No known key found for this signature in database
GPG Key ID: ADE0C41DAB221FCC
1 changed files with 10 additions and 2 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

12
modules/README.adoc
View File

@ -12,15 +12,23 @@ These are various modules ranging from link:https://nixos.org/manual/nixos/stabl
While there are different environments we can make modules with, there are commonalities between these custom modules. While there are different environments we can make modules with, there are commonalities between these custom modules.
It's better that we lay this out with a list of guidelines. It's better that we lay this out with a list of guidelines.
* Custom modules are typically classified as private and public modules.
Private (or internal) modules are simply modules meant to be used in this project and nowhere else.
Public modules are meant to be used by others (but not necessarily mean we have to support or maintain these for them).
* As such, public modules are not allowed to use the private library and modules.
Only the private modules can.
Public modules should strive to be usable without additional dependencies from this project at all.
* Absolutely no reliance on third-party modules. * Absolutely no reliance on third-party modules.
This makes the custom modules easier to import whether it's used with flakes or not. This makes the custom modules easier to import whether it's used with flakes or not.
Instead I recommend to make full use of environment-specific module structuring (such as host-specific modules on NixOS, user-specific modules on home-manager) on their respective environment configurations. Instead, I recommend to make full use of environment-specific module structuring (such as host-specific modules on NixOS, user-specific modules on home-manager) on their respective environment configurations.
As a bonus, this makes it easier to upstream them if we want to. As a bonus, this makes it easier to upstream them if we want to.
* That said, custom modules can rely on other custom modules. * That said, custom modules can rely on other custom modules.
Otherwise, we're just limiting ourselves by forcing the modules to be standalone. Otherwise, we're just limiting ourselves by forcing the modules to be standalone.
Plus we could fix encountered issues with our own solution (and even upstream them if possible). Plus we could fix encountered issues with our own solution (and even upstream them if possible).
* Follow the upstream module design as much as possible. * Follow the upstream module design as much as possible even for private modules.
This makes it easier to design custom module extensions around them. This makes it easier to design custom module extensions around them.
(Also a bonus for easier time upstreaming the module if I want to.) (Also a bonus for easier time upstreaming the module if I want to.)