Feature Request: Flatpak Support

[JoshuaFern]

trafficstars

Description

This feature request represents two individual but linked considerations:

1. Managing Flatpak via home-manager
2. Adding Flatpak support to existing home-manager modules.

Flatpak Module

A new module for home-manager supporting Flatpak could include a user defined list of applications to install. For example:

flatpak.enable = true;
flatpak.packages = [ org.mozilla.firefox ];
flatpak.update = true;

On activation it would dispatch the shell command ${pkgs.flatpak}/bin/flatpak install --user --assumeyes ${flatpak.packages} and then ${pkgs.flatpak}/bin/flatpak update --user --assumeyes, with --user specifying to install that application only for the user (flatpak installs applications system-wide by default, requiring the password), and --assumeyes for an unattended install without user interaction.

Finally, home-manager could set application permissions, such as:

flatpak.permissions."com.valvesoftware.Steam".reset = true;
flatpak.permissions."com.valvesoftware.Steam".filesystem = [ /nix ];

On activation running the shell command flatpak override --reset com.valvesoftware.Steam and ${pkgs.flatpak}/bin/flatpak override --user com.valvesoftware.Steam --filesystem=/nix, we need the reset command if we want permissions to be able to be removed from future home-manager generations.

Flatpak Support

Adding Flatpak support to existing home-manager modules.

I propose adding a new user-configurable option to every home-manager module called paths with a data type list such as programs.mpv.configPaths = [ ~/.var/app/io.mpv.Mpv/config/mpv ]; this would allow complete freedom to place the configuration anywhere or even in multiple places and for multiple programs. For example, placing the Firefox configuration in a fork's directory and Firefox's directory. This could eliminate the need to have a separate module for Librewolf.

An alternative to the above could be a new boolean option for application modules called flatpak like programs.firefox.flatpak = true which would move the config directory to ~/.var/app/org.mozilla.firefox/.mozilla, it could also disable the installation of the Firefox nix package. Note that in Flatpak the $XDG_CONFIG_HOME is in config instead of .config for XDG respecting applications and that every application has a Flatpak specific identifier such as org.mozilla.firefox that would need to be included in the module as perhaps a variable.

Q&A

Q: Why use Flatpak over Nix?

A: There can be reasons to pick Flatpak over Nix for specific software. One may want software to be isolated and control permissions via Flatpak's sandboxing.

Q: Is this out-of-scope for home-manager?

A: Perhaps, however home-manager options and the final configuration files are pretty agnostic and should be able to be applied to software installed from other sources.

Q: Won't this vastly increase activation time?

Flatpak installations are generally faster than Nix because they only download deltas of the changes in an application update. Also it's a completely optional module.

Comments, questions, and concerns are welcome.

[haedrichowen]

This would be so epic

[McDread]

Yes, to both considerations please!

[redxtech]

While this isn't implemented yet, check this out in the mean time: https://github.com/gmodena/nix-flatpak

I've been using this module for a while now, and while it's not as reproducible as would be optimal, it works well for installing a consistent set of flatpaks, both as a nixos module and a home-manager module.

[stale[bot]]

Thank you for your contribution! I marked this issue as stale due to inactivity. Please be considerate of people watching this issue and receiving notifications before commenting 'I have this issue too'. We welcome additional information that will help resolve this issue. Please read the relevant sections below before commenting.

If you are the original author of the issue

• If this is resolved, please consider closing it so that the maintainers know not to focus on this.
• If this might still be an issue, but you are not interested in promoting its resolution, please consider closing it while encouraging others to take over and reopen an issue if they care enough.
• If you know how to solve the issue, please consider submitting a Pull Request that addresses this issue.

If you are not the original author of the issue

• If you are also experiencing this issue, please add details of your situation to help with the debugging process.
• If you know how to solve the issue, please consider submitting a Pull Request that addresses this issue.

Memorandum on closing issues

Don't be afraid to manually close an issue, even if it holds valuable information. Closed issues stay in the system for people to search, read, cross-reference, or even reopen – nothing is lost! Closing obsolete issues is an important way to help maintainers focus their time and effort.