Support for non-systemd service managers.

Animeshz commented 11 months ago

Description

Many of major projects such as Mic92/sops-nix and even some of home-manager's module within service.* namespace depend on systemd.* options for populating services at the time of activation.

I've been stuck many times due to this as I don't have systemd as my service manager (runit instead) yet want to use home-manager as a portable and reproducible solution for managing most of packages in the system.

For nixos, it might seem counter-intuitive, even tho there's a rfc going on for it, but for home-manager a portable service layer would actually serve really great. Projects like numtide/devshell have used procfiles and honcho based approach for services after long discussions.

Not proposing a breaking change, there could be a conversion layer for a portable service interface like there is on fish config from shell options.

zeorin commented 11 months ago

Relevant RFC: https://github.com/NixOS/rfcs/pull/163

Animeshz commented 11 months ago

Actually this would be much more simpler to implement in home-manager as it already do uses something like that in fish module. NixOS part is much more complex and will require much more attention that's why I previously didn't linked the exact RFC.

zeorin commented 11 months ago

Personally, it annoys me that home-manager and NixOS use a different schema for systemd unit files. I figured this might be an opportunity to align with what NixOS will/might be doing.

stale[bot] commented 8 months ago

Thank you for your contribution! I marked this issue as stale due to inactivity. Please be considerate of people watching this issue and receiving notifications before commenting 'I have this issue too'. We welcome additional information that will help resolve this issue. Please read the relevant sections below before commenting.

If you are the original author of the issue

* If this is resolved, please consider closing it so that the maintainers know not to focus on this. * If this might still be an issue, but you are not interested in promoting its resolution, please consider closing it while encouraging others to take over and reopen an issue if they care enough. * If you know how to solve the issue, please consider submitting a Pull Request that addresses this issue.

If you are not the original author of the issue

* If you are also experiencing this issue, please add details of your situation to help with the debugging process. * If you know how to solve the issue, please consider submitting a Pull Request that addresses this issue.

Memorandum on closing issues

Don't be afraid to manually close an issue, even if it holds valuable information. Closed issues stay in the system for people to search, read, cross-reference, or even reopen – nothing is lost! Closing obsolete issues is an important way to help maintainers focus their time and effort.

drupol commented 7 months ago

Supporting non-systemd might help when it comes to installing a home-manager profile in a OCI container (pkgs.dockerTools).

rycee commented 7 months ago

@drupol For containers, you may be able to get away with using something like https://github.com/gdraheim/docker-systemctl-replacement and setting systemd.user.systemctlPath. I've never tried it though.

It seems to add a Python dependency, though. Perhaps there is a similar, more lightweight equivalent somewhere, though. If not, perhaps it's not too tricky to implement the bare minimum.

stale[bot] commented 3 months ago