Any update here?

Hm is this backwards compatible? Because before this PR people would use /op commands to imperatively write ops.json, even if declarative = true. But with this PR it would not use the previous ops.json anymore.

Current .declarative design seems to block backward compatibility as any future components being "declarativized" is gonna to forcefully override it. Moreover, it yields file permission error because of the existence of .devlarative will not chmod +w the newly added file.
Also, if any part of the declarative files which need write permission got accidentally deleted, it would not work even after rebuild, since chmod will not be executed. This means there is a flaw in current design itself as well.
I think we should come up with a better mechanism for declarative file components management to both address backward compatibility and robustness.

Yeah that would be nice. One thought I've had for a while is to be able to toggle options between being static and dynamic. The static implementation of it would be declarative using the NixOS config (which is declarative, but also slow to change), and the dynamic implementation would allow runtime configuration. Changing an option between static and dynamic is still a bit hard though.

Yeah that would be nice. One thought I've had for a while is to be able to toggle options between being static and dynamic. The static implementation of it would be declarative using the NixOS config (which is declarative, but also slow to change), and the dynamic implementation would allow runtime configuration. Changing an option between static and dynamic is still a bit hard though.

Wouldn't that be the same as having a declarative option?
Painless converting seems to be hard, but I think user themselves should be responsible for their data.

Wouldn't that be the same as having a declarative option?

It would be a declarative option for every option separately. So you could e.g. do something like

{
  services.minecraft = {
    whitelist.declarative = true;
    whitelist.value = [ ... ];
    ops.declarative = false;
    # ops is taken from /var/lib/minecraft/ops.json
  };
}

And that without having to declare all the declarative options manually (so it would be a builtin module system feature)

A competing PR has been opened a few months ago: #107308

Okay how about this: Only when declarative == true and ops != {}, the ops.json file is overridden. This should be backwards compatible.

That sounds good to me @infinisil. I would like the same to be true for other options. Personally I would use immutable ops and properties, but a mutable whitelist managed in-game by the ops.

I marked this as stale due to inactivity. → More info