NUR
NUR copied to clipboard
Namespacing of NixOs Modules following the addition of other OS's
PR #98 describes how to write and import your own home-module modules & configuration. This started a discussion on what the best-practices for doing so is, and what to do as more systems (crostini, macbook, init.d?, windows?) are added in the future.
With this in mind, I have pulled out the discussion into a separate Issue.
Please refer to the following thread for context: https://github.com/nix-community/NUR/pull/98#discussion_r315204124
Currently the following are being discussed:
- Home-Manager:
hmModules
- Darwin:
ndModules
-
Crostini:
crosModules
Possible actionables:
- extend the template default.nix to include these namespaces
- add documentation about the expected locations of these namespaces
- all the above
CC @rycee @Mic92
What is Crostini?
https://chromium.googlesource.com/chromiumos/docs/+/master/containers_and_vms.md
Custom LXC containers running on a chromebook. It's not technically Crostini specific, but I have a few services which I have copied over from NixOs and reworked to run under the user-account.
As I mentioned in that PR the naming scheme I would prefer is
-
repos.abc.modules.nixos.xyz
-
repos.abc.modules.home-manager.xyz
-
repos.abc.modules.nix-darwin.xyz
- …
The attribute path gets quite long but at least it is quite clear.
Unfortunately, since repos.abc.modules
currently is used for NixOS modules this naming scheme is not backwards compatible. But perhaps this is not too bad? Since the naming of attributes under repos.abc
is under the control of abc
they could choose the existing scheme or this new one.
I kind of screwed myself by having a repos.rycee.modules.home-manager
module that actually is a NixOS module but I suspect most other users could keep the old attributes for backwards compatibility if they want to switch scheme.
There was a response on the mailing-list which doesn't seem to have been propogated over here. (EDIT Found it: #51)
-
repos.abc.nixos.modules.xyz
-
repos.abc.home-manager.modules.xyz
The reason for this is that one can more easily add additional operating-systems without having to conform to a specified top-level.
Potentially if there are top-level things, such as packages, then it may be worth doing something there:
-
repos.abc.pkgs.emacs
-
repos.abc.darwin.pkgs.emacs
(if only mac compatible)
The migration sounds a bit painful for both users/repo owners. How would you implement that?