build: Add Nix/NixOS support#823
Conversation
There was a problem hiding this comment.
Defines how the script-server would be configured in NixOS.
With enable = true; we "install" the script-server. settings is a Nix "attribute set" / dictionary that is placed unchanged in JSON format to /etc/script-server/conf.json. configuration is the path to the script configuration.
Example:
services.script-server = {
enable = true;
# Optional
settings = { }; # JSON config in Nix syntax
# Optional
configuration = "..."; # Path to `conf` / `database` folder; Default: "/var/lib/script-server/conf"
};| config = lib.mkIf cfg.enable { | ||
| environment.systemPackages = [ cfg.package ]; | ||
|
|
||
| environment.etc."script-server/conf.json".source = |
There was a problem hiding this comment.
"Settings" could be put under /etc/script-server/conf.json when using NixOS.
| --tmp-folder /tmp | ||
| ''; | ||
|
|
||
| # `main.py` expects `web` to be in working directory. |
There was a problem hiding this comment.
From my understanding: When launcher.py is used, the web folder must be co-located to it. We could bundle the NixOS package so that this is always the case and keep calling launcher.py. But... according to the Filesystem Hierarchy Standard, we probably should put launcher.py under /usr/bin/launcher.py and would then need to put the web folder there as well which feels off.
Instead, we call main.py and set the working directory to where the web package is located in the systemd unit. It feels hacky and I think we need to put version.txt there as well...
(I think this is not specific to NixOS. Packaging for e.g. Ubuntu would raise the same questions?)
There was a problem hiding this comment.
But working dir is used not only for web, is it? All other folders from the release are expected to be there
There was a problem hiding this comment.
This builds the backend.
There was a problem hiding this comment.
This builds/bundles the frontend.
| /venv2/ | ||
| e2e_venv/ | ||
|
|
||
| # Nix / NixOS |
There was a problem hiding this comment.
result is for Nix build artifacts. There is also a qemu demo startable via nix run .#demo. Since the demo will instantiate a VM, we ignore the .qcow2 hard drive, too.
|
How is it supposed to be used/built? Imagine that I'm a normal Nix user (which would be a bad example, since I have no clue about nix), who would like to start using script server. |
|
If you have Nix installed (see https://nixos.org/download/), If you are on NixOS system, you could (almost*) only add You can look at, e.g., https://wiki.nixos.org/wiki/Nginx to get a feeling for NixOS. You could think about it being a "wrapper" over everything Linux/packages that allows you to fully declaratively and reproducibly define your running system. If you decide later to not wanting a software/service anymore, you delete the lines from your config and everything is cleanly rebuild w/o the software/service from scratch. f you feel this is going in the right direction, I would love to add a little to the *) We currently also need to point the system to this repo, but let's see how far we come :-) |
bugy
left a comment
There was a problem hiding this comment.
In general looks fine to me (considering that I have no clue about nix ecosystem)
But I would highly prefer to put all these files into tools/nix folder
To avoid polluting the main folder
Also, I would rather put "demo" config (if possible) into wiki section of github
| --tmp-folder /tmp | ||
| ''; | ||
|
|
||
| # `main.py` expects `web` to be in working directory. |
There was a problem hiding this comment.
But working dir is used not only for web, is it? All other folders from the release are expected to be there
|
|
||
| src = ../web-src; | ||
|
|
||
| npmDepsHash = "sha256-aBZDh2NcDU4OpsdTS8JqwGMa8WeIoyW9I6bUwTXfllU="; |
There was a problem hiding this comment.
Can it be automatically calculated as a result of some build tool?
There was a problem hiding this comment.
Actually it would be the same for "version"
There was a problem hiding this comment.
The hash ensures that we always downloaded the exact same npm dependencies. We could adapt the hash in CI when updating the deps, though, to make our life easier. But I would suggest to tackle this later.
If you don't mind, I'll take care about the maintenance of the Nix support. Ideally, the files can eventually be moved into nixpkgs but I don't have experience here and probably want to ask someone before starting anything :-) Let's see first how well this works.
Since you seem fine with the direction, I'll try to finalize the PR soon(tm) and write a short NixOS Wiki entry.
There was a problem hiding this comment.
soon = "probably next week";
Hello, and sorry for the delay!
Here comes the first version (where I avoided depending on a configurable
webfolder.) I've added a few comments inline.Why do we want it?
NixOS integration
With the files in place, NixOS users can (basically) add ...
... to their NixOS configuration and get a fully configured (systemd) script-server.
Linux VM demo
With the files in place, Nix users can start a live qemu VM demo with script-server preconfigured via ...
Linux image creation
With the files in place, Nix users can create {qemu,lxc,oci,...} images with script-server preinstalled and preconfigured by running ...
Especially LXC containers could make a lot of sense since they can be run natively on Proxmox.
Full list of supported images
NixOS test integration
With the files in place (and a little more effort), we could provide end-to-end integration tests where we automatically spawn a script-server via qemu and run all kinds of integration tests.