Portables would just be a convenience module in the Nixpkgs Module System.
It’s an instance of an application agnostic module, so that’s fun.
# extend-option.nix (or portable.nix)
{ extendModules, lib, ... }: {
options.extend = lib.mkOption {
description = "Extend this configuration or submodule with another module";
};
config.extend = module: (extendModules {
modules = [ module ];
}).config;
}
Usage:
# configuration.nix
{
# EDIT: oops, posted wrong snippet
# services.nginx.virtualHosts."foo" = { ... }: {
imports = [ ./extend-option.nix ];
# };
}
$ nixos-rebuild repl
nix-repl> config.networking.hostName
"nixos"
nix-repl> c = config.extend { networking.hostName = lib.mkForce "bar"; }
nix-repl> c.networking.hostName
"bar"
I don’t feel like it makes things portable; just extensible, but maybe something flew over my head at 1 AM
I think it might be confusing if we start a module based Portable Service Layer implementation, because that would just use imports, and have no use for extendModules or this extend option iirc.
For context:
NixOS:master ← hercules-ci:service-abstraction-layer
opened 09:46PM - 12 Nov 23 UTC
## Description of changes
- A proof of concept to hopefully illustrate what I… [had in mind](https://github.com/NixOS/rfcs/pull/163#discussion_r1347854623) for https://github.com/NixOS/rfcs/pull/163
It implements a bit more than necessary, allowing an abstract service to potentially create multiple systemd services, if it seeks out `options?systemd` to figure out the kind of process manager it's loaded into.
I think that's nice functionality, but the proof of concept could be changed to something more restrictive if that's the direction you want to take. (ie don't define process-manager specific options; only read the data from the abstract service)
I hope this gives some insight into what's possible with the module system.
Or maybe you can learn some useful techniques. This kind of module based infrastructure doesn't exist in NixOS yet. Closest thing would be flake-parts, for which I originally wrote `types.deferredModule`.
Anyway, a good starting point is the `example` directory. It's the closest thing to actual documentation.
(Again, sorry, proof of concept status, time, etc etc)
## Things done
- Built on platform(s)
- [ ] x86_64-linux
- [ ] aarch64-linux
- [ ] x86_64-darwin
- [ ] aarch64-darwin
- For non-Linux: Is sandboxing enabled in `nix.conf`? (See [Nix manual](https://nixos.org/manual/nix/stable/command-ref/conf-file.html))
- [ ] `sandbox = relaxed`
- [ ] `sandbox = true`
- [ ] Tested, as applicable:
- [NixOS test(s)](https://nixos.org/manual/nixos/unstable/index.html#sec-nixos-tests) (look inside [nixos/tests](https://github.com/NixOS/nixpkgs/blob/master/nixos/tests))
- and/or [package tests](https://nixos.org/manual/nixpkgs/unstable/#sec-package-tests)
- or, for functions and "core" functionality, tests in [lib/tests](https://github.com/NixOS/nixpkgs/blob/master/lib/tests) or [pkgs/test](https://github.com/NixOS/nixpkgs/blob/master/pkgs/test)
- made sure NixOS tests are [linked](https://nixos.org/manual/nixpkgs/unstable/#ssec-nixos-tests-linking) to the relevant packages
- [ ] Tested compilation of all packages that depend on this change using `nix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD"`. Note: all changes have to be committed, also see [nixpkgs-review usage](https://github.com/Mic92/nixpkgs-review#usage)
- [ ] Tested basic functionality of all binary files (usually in `./result/bin/`)
- [23.11 Release Notes](https://github.com/NixOS/nixpkgs/blob/master/nixos/doc/manual/release-notes/rl-2311.section.md) (or backporting [23.05 Release notes](https://github.com/NixOS/nixpkgs/blob/master/nixos/doc/manual/release-notes/rl-2305.section.md))
- [ ] (Package updates) Added a release notes entry if the change is major or breaking
- [ ] (Module updates) Added a release notes entry if the change is significant
- [ ] (Module addition) Added a release notes entry if adding a new NixOS module
- [ ] Fits [CONTRIBUTING.md](https://github.com/NixOS/nixpkgs/blob/master/CONTRIBUTING.md).
<!--
To help with the large amounts of pull requests, we would appreciate your
reviews of other pull requests, especially simple package updates. Just leave a
comment describing what you have tested in the relevant package/service.
Reviewing helps to reduce the average time-to-merge for everyone.
Thanks a lot if you do!
List of open PRs: https://github.com/NixOS/nixpkgs/pulls
Reviewing guidelines: https://nixos.org/manual/nixpkgs/unstable/#chap-reviewing-contributions
-->
2 Likes