Skip to content

nixos module rework#212

Draft
PhilTaken wants to merge 2 commits intomasterfrom
phil/nixos_module_rework
Draft

nixos module rework#212
PhilTaken wants to merge 2 commits intomasterfrom
phil/nixos_module_rework

Conversation

@PhilTaken
Copy link
Member

@PhilTaken PhilTaken commented Jan 9, 2025

This PR addresses a few complaints that were raised about the state of the NixOS module component by rewriting it to utilize dumping relevant context as json in python and sourcing that json in nix instead of attempting to convert python objects straight to nix code.

TODOs

  • changelog
  • documentation
  • a defined transition from the old implementation to the new one

addresses a few complaints that were raised about the state of the nixos
module component by rewriting it to utilize json dumping in python and
json loading in nix instead of converting python objects straight to nix
code.
@PhilTaken PhilTaken requested a review from Ma27 January 9, 2025 14:38
self.map(basename.replace(".nix", "_component.json")),
data=json.loads(
json.dumps(
self.source_component or self.parent,
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think this needs special casing for Address/NetLoc.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

A lot of components will require special handling, especially custom ones. I'm very much not sure how to handle this properly. The question is where do you draw the line honestly. I'd prefer as little special handling as possible.

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'd prefer as little special handling as possible.

I don't disagree.
But it seems as if Address isn't evne JSON serializable, so currently the NixOSModule code would fail with such components, correct?
Ideally one could make classes JSON serializable in Python, but I'd have to do some more research, i.e. not now.

sensitive_data=True,
);
in {
imports = [(module (args // { inherit component; }))];
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

fwiw, I think what I'd prefer here is actually

{ component, ... }:
{ config, lib, pkgs, ... }:
{

}

i.e. a function that generates a module given the component context instead of mixing this together with _module.args (if this ever gets a component-key, it will be funny).

I'm not sure if there's a transition path that's not just a pile of hacks, so we probably have no choice and need to leave this.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Honestly, that is a better version.

Transitioning would have to be manual but could just be part of any regular maintenance. The change is not too drastic that we'd have to account for it in this component.

tiny change but I'd change it to just

component:
{ config, lib, pkgs, ... }:
{

}

since there are no other arguments to pass here

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

since there are no other arguments to pass here

fine by me.
This will require an entry in the release notes then, though.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

100%, this is a breaking change

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants