update.onActivation Is very confusing

[thomasfinstad]

First, thanks for the work you have done, I really like using flatpaks for desktop apps and you made that very easy.

I am having a hard time understanding the real intention of onActivation.

Whether to enable flatpak to upgrade applications during
{command}nixos system activation. The default is false
so that repeated invocations of {command}nixos-rebuild switch are idempotent.

implementation: appends --or-update to each flatpak install command.

I don't understand how the implementation achieves the stated goal.

How I understand it from the description this option, when set to false, the install / update will not be triggered by nixos-rebuild, but that is not what the implementation does at all. It also seems to be completely irrelevant if auto update is enabled.

nix-flatpak/modules/installer.nix

Line 78 in 8bdc254

updateApplications = cfg.update.onActivation || cfg.update.auto.enable;

I think the option should either change name to match the effective implementation, or change the implementation to match the name/description.

But if the option works and is described as intended and its just me being dumb then I think it would be very nice to have an option that can stop the service from restarting during a nixos-rebuild or perhaps change the service to be a forking type that would be helpful since running a rebuild can be excessively slow currently, as the service blocks until it has completed its work.

[gmodena]

Hey @thomasfinstad ,

thanks for reaching out.
Agree. onActivation, as currently implemented and documented, is a mess.

How I understand it from the description this option, when set to false, the install / update will not be triggered by nixos-rebuild, but that is not what the implementation does at all.

This should be the intended behavior, though in practice the current implementation tries (wrongly) to install packages anyway.

This is related to #110, which I plan to pick up next.

It also seems to be completely irrelevant if auto update is enabled.

That's currently expected behavior, though it may be poorly documented. At the time, it seemed like a good idea to have auto.update trigger an install upon activation, but that might be something worth reconsidering before hitting 1.0.0 (that should become a stable API).

What's your take on this?

[thomasfinstad]

Thanks for getting back to me so quickly on this.

My thoughts on this would be fairly "categorized" since I like to group stuff.

update.auto.onCalendar updates the pkgs on a schedule, with it being disabled when null?

onActivation updates pkgs during a nixos-rebuild, independent of the onCalendar, perhaps renamed to "onRebuild"?However I think it would be less confusing if it was moved to be update.auto.onActivation, as that would indicate the enable/disable is relevant here too, and it is an automatic function so makes sense grouping wise.

Edit: onActivation should not be enabled if set to false in my opinion. And if you use null as a deactivation switch on onCalendar, then the enable/disable option will be redundant and can get cleaned up.

[thomasfinstad]

another thought is maybe it would be worth while to flip the update.auto around to auto.update

This would allow a better grouping of all automatic tasks. This would be relevant to #96 which could then be auto.remove.unused right next other auto tasks.

auto = {
  update = {
    onActivation = false;
    onCalendar = "leapyearly";
  };
  remove = {
    unused = {
      onActivation = false;
      onCalendar = "leapyearly";
    };
    unmanaged = {
      onActivation = false;
      onCalendar = "leapyearly";
    };
  };
};

Probably have some spelling errors etc, but you get the point.