lib/services: move portable service infrastructure out of nixos/

[KiaraGrouwstra]

Move the portable modular service base from nixos/modules/system/service/portable/ to lib/services/, making it importable by any module system (home-manager, nix-darwin, ...) without reaching into the nixos/ tree, given this should not actually depend on NixOS.

No functional changes - only import paths differ.

Precursor to #506343.

Things done

• Built on platform:
  • x86_64-linux
  • aarch64-linux
  • x86_64-darwin
  • aarch64-darwin
• Tested, as applicable:
  • NixOS tests in nixos/tests.
  • Package tests at passthru.tests.
  • Tests in lib/tests or pkgs/test for functions and "core" functionality.
• Ran nixpkgs-review on this PR. See nixpkgs-review usage.
• Tested basic functionality of all binary files, usually in ./result/bin/.
• Nixpkgs Release Notes
  • Package update: when the change is major or breaking.
• NixOS Release Notes
  • Module addition: when adding a new NixOS module.
  • Module update: when the change is significant.
• Fits CONTRIBUTING.md, pkgs/README.md, maintainers/README.md and other READMEs.

[roberth]

Not sure if this should go into lib/, as it's not even really connected to lib proper.

Maybe we should actually carry out the division into multiple "libs" that better reflects the purposes and maintenance models for these things.

• Something like flake: Add libs #413205
  where it would be naturally separate from the core lib

Still inclined to merge as that could be figured out and agreed upon later.

[nixos-discourse]

This pull request has been mentioned on NixOS Discourse. There might be relevant details there:

https://discourse.nixos.org/t/prs-already-reviewed/2617/2913

[eveeifyeve]

I agree with @roberth, However this can be argued later. Apart from that, the rest LGTM/SGTM.

[baileylu121]

It would also be nice if we have a proper attribute to reference for portable-lib instead of a file path we have to manually import, something like lib.portable or the lib division @roberth was talking about, since this change won't be backwards compatible (mind you this only effects a grand total of ~2 non nixpkgs repositories based on a quick github search, so it's not a huge concern)

[eveeifyeve]

It would also be nice if we have a proper attribute to reference for portable-lib instead of a file path we have to manually import, something like lib.portable or the lib division @roberth was talking about, since this change won't be backwards compatible (mind you this only effects a grand total of ~2 non nixpkgs repositories based on a quick github search, so it's not a huge concern)

This is probably best done in a followup pr, as this seems to be a nitpick more than of a merge blocker.

[KiaraGrouwstra]

It would also be nice if we have a proper attribute to reference for portable-lib instead of a file path we have to manually import, something like lib.portable or the lib division @roberth was talking about, since this change won't be backwards compatible (mind you this only effects a grand total of ~2 non nixpkgs repositories based on a quick github search, so it's not a huge concern)

opened #507052 now for this.
i'm hoping lib.services might help alleviate confusion from the internal 'portable' vs external 'modular' naming, but feedback welcome there...