feat: add batteries.user-modules

[lonyelon]

Works exactly like batteries.host-modules but in reverse, allowing host.classes from the user aspect tree to be projected into onto hosts that include it.

Test plan

I added this to my user aspect:

{
  den.aspects.sergio.nixos = { pkgs, ... }: {
    environment.systemPackages = [ pkgs.htop ];
  };
}

After that I rebuilt and saw no htop in my system as expected.

After including this (icebear is my main PC):

{ den, ... }: {
  den.aspects.icebear.includes = [ den.batteries.user-aspects ];
}

I get htop as expected.

[sini]

It might be better if this battery was explicit as to which user(s) it would apply to.

With host -> users it's a 1:many relationship; with users -> host it's a many:1.

I'd also like to see some tests to validate behavior/guard against future regressions. Implementing it as a policy is correct. :)

Also, we'll need to add it to the batteries docs page after we get the implementation details nailed down. But we can focus on implementation details first.

[lucasshiva]

It might be better if this battery was explicit as to which user(s) it would apply to.

Perhaps this could be set in the user aspect, just like den.batteries.host-aspects.

Also, we'll need to add it to the batteries docs page after we get the implementation details nailed down. But we can focus on implementation details first.

den.batteries.host-aspects is also lacking documentation. It's not mentioned on either the Use Batteries page nor the Host<>User Mutual Config page, which may be an oversight.

[lonyelon]

Okey, I didn't have much time to work on this on the last weeks but I'll do my best.

It might be better if this battery was explicit as to which user(s) it would apply to.

Maybe? I like it the way it is now. Keeps the user unaware of the hosts it runs in. It just knows what configurations the hosts will have.

Perhaps this could be set in the user aspect, just like den.batteries.host-aspects.

Could be.

PD: I have been using this branch of Den since I created it without issues. I like how this works.

[lucasshiva]

PD: I have been using this branch of Den since I created it without issues. I like how this works.

I like it too. Personally, I think the behavior of host-aspects and your user-aspects should be the default for Den. In my opinion, it just makes a lot more sense to have this kind of bi-directional configuration be the default. But I understand some people might not want this, so unless we want to introduce breaking changes, the best way to solve this is making these batteries opt-in rather than the default behavior. The problem is that it's hard to decide who should opt-in. Is the user? Is it the host? At the moment, we have this:

• den.batteries.host-aspects: Users opt-in. Applies to all hosts.
• den.batteries.users-aspects: Hosts opt-in. Applies to all users.

Perhaps we could make it opt-in for both host and user? As in, both user and host requiring the include of host-aspects for the functionality to work?

[vic]

I like it too. Personally, I think the behavior of host-aspects and your user-aspects should be the default for Den.

I think that was the default behaviour before, all users contributing to their hosts, and also pre 0.13 all hosts contributing to all users, so now that we are trying things to be more controlled/explicit (hosts / users opt-in) I agree that having the battery included at user level is like that single user explicitly opting-in, and since Den allows to include for-all users we have best of both worlds (fine grained and everybody opts in)

I like the simplicity of the battery, btw.

[lucasshiva]

I like it too. Personally, I think the behavior of host-aspects and your user-aspects should be the default for Den.

I think that was the default behaviour before, all users contributing to their hosts, and also pre 0.13 all hosts contributing to all users, so now that we are trying things to be more controlled/explicit (hosts / users opt-in) I agree that having the battery included at user level is like that single user explicitly opting-in, and since Den allows to include for-all users we have best of both worlds (fine grained and everybody opts in)

I didn't know that. I've only started using Den a couple of days ago, so it was already on 0.17.

I like the simplicity of the battery, btw.

I like it too, but den.batteries.host-aspects does apply to all hosts by default, no? If the idea is to be more fine-grained, which is totally fine, then perhaps hosts also should opt-in to the battery. Otherwise, sergio's user-aspects, where a host opts-in and it applies to all users by default, should be in good enough state to be merged.

[sini]

den.batteries.host-aspects does apply to all hosts by default, no?

If you define it that way; yes -- but it doesn't have to. I'll enhance the host.user API soon so it's more clear how you'd configure beyond just den.aspects.username for expressing what the local pipeline resolution should be.

[sini]

Personally, I think the behavior of host-aspects and your user-aspects should be the default for Den.

I disagree, especially when you consider den as a generic resolution pipeline looking to extend to real world infra problems as well. The example I often give is my wife shouldn't be forced to learn and use hyprland just because I've configured it on one of our shared hosts. She should also be free to choose her own stylix themes, or not use stylix at all. Nix's isolation is one of it's core value offerings as a distribution versus other distros where rpm/apt/pacman installing something default installs it for everyone because there is no isolation.

Disabling the isolation by default is the wrong choice. I know that there's probably some friction there, but I truly believe that its the right choice.

[lucasshiva]

The example I often give is my wife shouldn't be forced to learn and use hyprland just because I've configured it on one of our shared hosts. Disabling the isolation by default is the wrong choice. I know that there's probably some friction there, but I truly believe that its the right choice.

I'd prefer if it were the default, but it's okay as long as we can opt-in. I have no strong feelings about this.

Also, for your wife's use case, that would be a matter of leaving host config very thin and moving things to her user. For instance, if the host didn't include hyprland, she'd also never get it without manually including it in her user's aspect. Or, if she used the same user in multiple hosts — and thus didn't want a "heavy" user config — it would be a matter of using provides to scope configuration to specific hosts. So, from how I see it, both ways (default or opt-in) work just fine, this is all just a matter of preference/design choices. And there's nothing wrong with that.

Again, I have no problems with including a battery. It's just that I'd prefer it as the default behavior because I don't see myself ever not including these batteries, which is why I think this user-aspects battery would be a good addition.

[theutz]

I generally agree with this, too. But I do yearn for a simple meta-battery that enables all the magic by default just for convenience. :) Like, there's no project where I don't want define-user and hostname batteries. And I want input' and self' on every flake-parts project by default.