Allow Specifying Overrides Folder

[Spaghetto392]

With some NixOS modules, you are allowed to specify a folder/file instead of writing the configuration within configuration.nix e.g. security.pki.certificateFiles and security.pki.certificates. Both accomplish roughly the same function, but one brings in configuration from an external file.

Allowing external override configuration files could help with organization of a users configuration.nix and also allow easier migration from traditional Flatpak installations by allowing a user to re-use their pre-existing override files.

[GermanBread]

So, you want to copy the overrides from another place (by symlinking them)?

Try postInitCommand

[GermanBread]

You know what, I'm just gonna go ahead an implement it.

Because it sounds cool.

[bayazidbh]

@GermanBread is postInitCommand still part of the definition? There's a note about it at the end, but home-manager said there's no such definition. I'm guessing preSwitchCommand is the preferred new command to use? Though, I am using postInitCommand to symlink my overrides so I don't know if that would create any issues.

    postInitCommand = ''
      /usr/bin/rm ${config.xdg.dataHome}/flatpak/overrides
      /usr/bin/ln -sifv ${config.xdg.configHome}/home-manager/flatpak/overrides ${config.xdg.dataHome}/flatpak/
    '';

Will test now and throw an update here if there's any issue.

[GermanBread]

Nope, postInitCommand and preInitCommand have been removed and replaced by more granular options

I need to update the docs

[Spaghetto392]

@GermanBread Just to clarify, is there an equivalent for postInitCommand? I've tried a few different options, and none of them seem to execute after the rest of manage-system-flatpaks.service which in my case breaks the solution I had in issue #11 for impermanence support. I should also mention, I've tried using preSwitchCommand.

[GermanBread]

Just to clarify, is there an equivalent for postInitCommand?

Not yet. I am unsure where to put such command because on one hand me thinks the commands should stop the generation from being created if it fails, but on the other hand there should be a post hook type of thing which is allowed to fail

[Spaghetto392]

I don't disagree with the above statement, but as it stands right now, it's left me in a bit of an odd scenario where roughly an hour into the system running I have to manually run the two commands referenced in #11 to make any and all Flatpaks work.

Maybe a potential idea would be to have a postInitCommand equivalent that runs after everything is done, and then have a failure state check that reverts the changes (e.g. if process exits as non zero?) In that case it could be a matter of asking the user via a NIX option whether they want the error checking enabled or not, which would allow you to sort of have both options for the user to use.

Alternatively, at least in my case, the install mechanism could be changed so instead of populating the normal Flatpak folder, you could populate an alternative folder that is then symlinked or bind mounted to where Flatpak expects programs to be installed. This would probably be better for the long term transition to using nix store (if that is still being considered,) albeit, in my scenario it would also have to recreate the symlink / bind mount every time on boot.

I'm not ultimately sure what would be better, maybe something I haven't thought of? Either way, I'd be glad to hear any input you could provide.

Should I open this a separate issue?

[GermanBread]

I think adding a non-checked post hook would be the best solution

[GermanBread]

I pushed something to dev, tell me your thoughts

[Spaghetto392]

@GermanBread Yep, works as intended. I do think eventually have some sort of checker would be useful though, like you said. Anyway, thank you. Also I like the name for the option.