Conversation
Fixed the flux capacitor again (auto-msg qwen2.5-coder:7b) On branch systemd Changes to be committed: (use "git restore --staged <file>..." to unstage) modified: modules/systemd/check.nix modified: modules/systemd/config.nix
Implemented a feature to make the coffee machine sing karaoke during mornin�[6D�[K mornings (auto-msg qwen2.5-coder:7b) On branch systemd Your branch is up to date with 'private/systemd'. Changes to be committed: (use "git restore --staged <file>..." to unstage) new file: modules/systemd/SCRATCH.nix Fixed the flux capacitor again (auto-msg qwen2.5-coder:7b) On branch systemd Your branch is up to date with 'private/systemd'. Changes to be committed: (use "git restore --staged <file>..." to unstage) modified: modules/systemd/SCRATCH.nix modified: modules/systemd/config.nix modified: modules/systemd/module.nix
| }; | ||
| }; | ||
| }; | ||
| extensionsSubmodule = { name, ... }: { |
There was a problem hiding this comment.
The systemd.{user,service} submodule, containing options for each unit file extension type
The interesting thing to note is extraMod which adds some extra per-service options for enabling or disabling various actions we perform in translating the options to unit files.
The code above this comment is just the systemd docs written out as nix options basically. Below is more interesting to figure out how it works. These options are processed in ./config.nix
|
@zenoli @iynaix @rachitvrma @FluxZA is anyone available and interested in reviewing or giving advice? This is still a work in progress but it should be most of the way there already. |
|
Hi @BirdeeHub |
It will definitely be waiting that long. Try to ignore the noise from the transposed systemd options when you do review it. |
|
Hi All I also will only have a chance to look over this on the weekend. I have some experience with systemd and how nixos handles it so hopefully I can help. Also happy to help out with documentation. |
|
Hey everyone, I have been quite busy with some college work. I'll be happy to look into this, though. |
|
My apologies, I did not get around to look at it, unfortunately I don't think I will have time in the next days :-( |
|
Hi, sorry this is a little late, my weekend was busier than I expected and I also ended up getting more absorbed in the manga I am reading than I planned 😂 I have gone through everything once, and I have some initial comments and questions. I haven't looked into the restart/logout issue yet, but I am still happy to if you want a second opinion. Regarding inclusion in the default module, I agree that this is not necessary and would probably lead to the docs being cluttered. I was even thinking you could potentially split the current module to separate the systemd options and the extra mods options, so that if you are reading the docs you know if you are looking at something systems related or something related to the nix-wrap implementation. This would also create more separation for if you wanted to work with other service handlers in future. This leads to the question of the docs for the systemd options. In my opinion we should have as many of them documented as possible, but keep the descriptions very basic with links to the systemd documentation. That way the docs aren't too bloated and if anything changes from systemd's side we don't have to maintain our docs to match the new behaviour. Regarding your implementation, I am unsure of how the overwrite or append would work. Is this catering for a case where the host system already has a service and the wrapper needs it to behave differently? Regarding docs, do you want help adding more docs or just reviewing the current docs? |
Close, it is catering for the case where the derivation already provides a service file with that name, for if you wish to modify it rather than overwriting it. If overwrite is true, it will just replace it. That is 1 vote for "not included in
I was going to add a I am more interested in people reviewing the top level options that are not directly translated, and the implementation, as opposed to the list of systemd options for each section and their docs, as those are just transcribed from |
|
Ahh okay, that makes sense. Cool I will go back and look at those descriptions in particular and leave comments if I have any. |
| let | ||
| extraMod = { _prefix, ... }: { | ||
| options = | ||
| let |
There was a problem hiding this comment.
The id generation here might benefit from some internal documentation. It took me a long time to figure out what it was doing (could just be a shortcoming in my nix knowledge though🤦🏼)
My understanding is that it is used to dynamically update the descriptions based of of where the extraMods function ends up being imported, using the last 3 levels of the option hierarchy if they exist. One thing I noticed when actually generating the docs, the final element (used in ${get 2}) seems to be a space for some of the options, I am not sure if that is intended.
There was a problem hiding this comment.
Let me know if this is not the type of doc suggestions you want. I had an hour to start looking this eve and this is the first thing I came across which I didn't understand. Will continue looking at more the rest of the week and I will try adjust feedback based on the level you are looking for.
4 participants
Things To Be Done / Questions To Answer:
wlib.modules.defaultor not?wlib.modules.default, not everything needs a service, and there are other service runners besides systemd.about the second one:
You can still start it yourself right away. It is installed, just not enabled.
The action to enable it has been done. Systemd does not know about that yet.
I am not entirely sure why you cannot
systemctl daemon-reloadorsystemctl daemon-reexec, but it seems like you have to log out or restart. It seems to check for enable status at a very particular time and then cache the results.I tried mirroring most of the options to nixos options, and that kinda solved this issue, but not entirely
When you mirror the options, nixos uses the overrides mechanism, so you can mirror just the wantedBy requiredBy and upheldBy options. It mostly solves the issue, but sometimes the service is enabled but doesn't seem to run until you restart anyway? But systemd is reporting everything should be running
home manager doesn't merge with the ones from the package, so we would need to mirror ALL of them for home manager and ignore the file from the package and this would not work with placeholders...
I think there is something that can be done with the generated install module that can work around this, maybe with an activation script that can solve this, but that is what has been taking so long. For now, the options work, they are a lot like the home manager ones, but you need to log out or restart the first time you add the service for it to be enabled. After that, changes are reflected on rebuild, as the old file no longer exists on the systemd path and has been replaced with a new one with the same name, so it inherits the enabled status and reflects the new values.
Also, sorry I have been absent the last week, will be getting back to it!