I am not sure if a way exists currently, though I am planning on solving this as part of my devos project, just haven’t nailed down a design spec just yet. I want to be able to transpose modules, between nixos, home-manager, nix-darwin and possibly devshell.
They may not be entirely equivalent, since devshell, for example, doesn’t support services, but I’m thinking what I’ll end up having to do is declare a generic module that then gets converted to the specified platform.
Another alternative I’ve considered is to start an initiative in each project to synchronize module API so we can easily pass them around. This may cause a lot of headaches though.
Thankfully, there is some overlap between NixOS and nix-darwin modules. So some of them may work just fine as is.
The framework has a variety of purposes – one of them is targeting multiple process managers from the same declarative specification (e.g. sysvinit, systemd, launchd etc.) and it should work on other operating systems than Linux, including macOS and FreeBSD.
It also has some other objectives, such as the ability to construct multiple instances of the same proces configuration and a switch to disable user authentication so that an unprivileged Nix user can deploy services.
Although it is already somewhat usable, it is currently still an unfinished prototype. There are two more major features on the planning.
Also, If we leave services out of it for a moment and just focus on static program configuration, extracting the relevant environment.etc, and environment.sessionVariables from existing nixos modules after they have been evaluated and passing it to nix-darwin would go a long way to creating a one way compatibility layer between the two, though probably not very efficient.
Current thing that needs nontirivial amount of work: see the end of discussion, importing pure standalone modules into a subtree, possibly multiple times into different places.