mu: run initialization command when personal addresses change

[VojtechStep]

Description

When the user changes which addresses mu should consider 'personal', mu's store should be reinitialized.

After this change, the activation script parses the previously configured list of addresses and compares it with the new one. If they differ, it runs the init command even when the store has already been initialized.

Checklist

• Change is backwards compatible.

• Code formatted with ./format.

• Code tested through nix-shell --pure tests -A run.all or nix develop --ignore-environment .#all using Flakes.

• Test cases updated/added. See example.

• Commit messages are formatted like

  {component}: {description}
  
  {long description}
  

  See CONTRIBUTING for more information and recent commit messages for examples.

• If this PR adds a new module

  • Added myself as module maintainer. See example.

Maintainer CC

@KarlJoad

[KarlJoad]

This looks interesting! I have long tinkered with this kind of thing in my head. Does this also handle the case where you add/remove only some addresses/aliases? I would like to codify the expected behavior of changing a subset of the addresses as an actual test that Nix/home-manager can run if we do go down this road.

[VojtechStep]

Does this also handle the case where you add/remove only some addresses/aliases?

On activation it asks mu for the current list of aliases, so any observable change to that (modulo order) should trigger a reinit.

I would like to codify the expected behavior of changing a subset of the addresses as an actual test that Nix/home-manager can run if we do go down this road.

I agree, though it would involve testing the actual side-effects of activation over multiple runs, and I don't know if the current test infra allows that.

[VojtechStep]

I agree, though it would involve testing the actual side-effects of activation over multiple runs, and I don't know if the current test infra allows that.

I tried to get the integration tests working, but I can't get a working internet connection in the VMs. In any case I'm pretty sure the patch works, since I've been using it for the past couple weeks, during which I manipulated my email addresses (adding new aliases and accounts), and mu always ended up in the expected state.

[teto]

willing to merge but can't review. @KarlJoad could you test/review and confirm it works ?

[KarlJoad]

I can review, but cannot test on real-world stuff. I do not use home-manager anymore and I don't want to impact my current mail setup.

I will post my review/approve by tonight CST.

[VojtechStep]

I'm not sure if I got the usage of run in the activation script right. On dry runs, should the check for currently registered email addresses run, so that the log correctly reflects if reinit would run or not, or should the check also not run?

[KarlJoad]

In my opinion, a dry-run should do everything a normal run should do, except for any actual modifications, that way you (as the user) can see exactly what will happen, without anything actually changing.

So dry-runs should check for currently-registered addresses.

[VojtechStep]

So dry-runs should check for currently-registered addresses.

I agree; fixed the check in dry-run mode and rebased on master.