nix-processmgmt

at it supports both pure usermode operation as well as functioning as an OS's init system. Anyway, all of 'em are in Nixpkgs, so you can pick them up and use them without any packaging work, too. Service orchestration and containers are basically orthogonal concerns. Before Docker was born, there were already plenty of portable tools for standalone "process supervision", "service management", whatever you wanna call it. So it is after Docker, as well. If I needed this for one of my dev environments I would take a look at process-compose to decide if it's acceptable to me. If it isn't, then after surveying the contemporary landscape of usermode service managers, I'd then write a devenv module that generates configs for it, and use that. > Should I run Nix in Docker, Docker from Nix, or is there a nix-only solution for this? I'd do this in a "Nix-only" way if possible, but if it's convenient for you to run a service via Docker (or Podman or any other container runtime), you can still do that. If you can safely assume that all of your devs have it available, you can ship the client (`docker` or `podman` CLI or whatever) as part of your Nix environment, then have your process manager launch it via that command line interface. I'd avoid running Nix from within Docker for the purposes of development environments. -- 1: https://supervisord.org/ 2: https://devenv.sh/ 3: https://devenv.sh/supported-process-managers/process-compose... 4: https://f1bonacc1.github.io/process-compose/ 5: https://sandervanderburg.blogspot.com/2020/02/a-declarative-... 6: https://github.com/svanderburg/nix-processmgmt 7: https://skarnet.org/software/s6/ 8: https://github.com/ddollar/foreman 9: https://shepherding.services/ 10: https://davmac.org/projects/dinit/

ocker containers also don't normally do any kind of service management, they're single-process images. They're not really comparable to orchestrated services managed by NixOS or Nix-Darwin modules. But if your concern is just shipping the same thing and you don't care about what's managing the services, a whole NixOS VM isn't any less efficient than some other VM in which you run `docker-compose` or Kubernetes. That said, there are Nix-y ways to ship one or more supervised processes in a way that's portable across the platforms that Nix supports. One way is with a manually tailored supervisord config with a nix-shell or something like devenv.sh. Another strategy would be to leverage something an abstraction layer like this one: https://github.com/svanderburg/nix-processmgmt

Nix and Nixpkg's fetchers as well, also using overlays, using the `nixpkgs.overlays` option in NixOS. This is how, for example, the community Emacs overlay recommends folks use it[2]. What you wanna do for projects that don't offer a flake.nix or a ready-made overlay is to use a fetcher like in the Emacs example, but write your own overlay function that invokes Nixpkgs' `callPackage` function on whatever Nix expression inside the repo represents the package you want, or imports them from a release or default.nix as appropriate. Home-manager uses this to define its own little overlay[3], the one that gets used in its flake.nix, and its package is just its default.nix[4]. Unfortunately, in the pre-flakes world, you just have to read the Nix code and figure out how to translate things to get the attributes you want into scope. For example, this works for nix-processmgmt: (final: prev: { nix-processmgmt-tools = (import ( (builtins.fetchTarball "https://github.com/svanderburg/nix-processmgmt/archive/6def8584c6b028c922c550859a0…") + "/tools/default.nix") { pkgs = prev.pkgs; } ); }) and then you can add, e.g., `nix-processmgmt-tools.common` to your `environment.systemPackages`. I think maybe the reason instructions aren't given for some projects is that they see those parts of the guide as mostly for beginners or casual experimenters, and they expect advanced or ‘serious’ users to be able to figure it out without much trouble. To some extent I think this is because different people choose to pin packages in the pre-flakes world through a variety of different mechanisms, and the authors of these packages and tools don't know in advance how you want to do it. In the case of nix-processmgmt, I think Sander doesn't actually expect to have any users! In such cases, an imperative install that users are expected to play with for a little while and then just throw away is supposed to be enough. You're right, though, that it's odd and disappointing that instructions for the preferred way of doing things are sometimes simply not given. A polite pull request or issue report would probably be well-received. My recommended strategy, if you get stuck, would be to ask for help getting those packages into scope declaratively on Discourse or Matrix, and then to offer the authors of these out-of-tree packages pull requests to modify their READMEs accordingly. :) PS: You don't necessarily _have_ to use overlays for these. You can also drop expressions that use builtins.fetchTarball and then use `callPackage` or import from those sources directly into lists of packages like `environment.systemPackages`. — 1: https://github.com/gytis-ivaskevicius/flake-utils-plus 2: https://github.com/nix-community/emacs-overlay#quickstart 3: https://github.com/nix-community/home-manager/blob/master/ov... 4: https://github.com/nix-community/home-manager/blob/master/de...

, an experimental Nix framework for writing Nix expressions to describe services to be managed by a range of process managers that may or may not be PID 1 (which means the could be usable on non-NixOS): https://github.com/svanderburg/nix-processmgmt • nix-darwin, a module system for macOS that provides some NixOS functionality, including managing services: https://github.com/LnL7/nix-darwin The discussion on the service abstraction layer for Nixpkgs/NixOS is also very relevant. It shows that there has been interest in something like this for many years, but it's never quite come together: https://github.com/NixOS/nixpkgs/issues/26067 I wouldn't assume it's just around the corner or inevitable. It is a really exciting possibility, though, and the nix-processmgmt framework seems like something that could evolve into a service abstraction layer for Nixpkgs that could make facilities for managing services available in a uniform way even on non-NixOS Linux.