[ Feature ] Config file for flatpak env

[fepitre]

Up to what I can read on flatpak configuration and execution, it is not possible to give a specific configuration file for setting specific 'flatpak config *' or environment variables. From what I'm seeing, 'flatpak config' currently allow to only set 'languages' option but we could imagine to setup more config options and store this into a file.

As a matter of example, 'http_proxy' variable could be set differently for flatpak instead of using the global one. Notably, 'dnf' and 'apt' allows to handle such variable in a configuration file.

As a matter of context: in QubesOS, we want to set it depending on VM type (the "same" system started in different instances) and only for flatpak, not all applications.

For more precision, I kindly invite you to have a look on https://www.qubes-os.org/doc/software-update-vm/#updates-proxy motivation for such feature.

[marmarek]

Another similar thing that could use a flatpak-specific config method is default installation (user / system). In QubesOS template-based VMs have only part of the system persistent (/home and few other directories). It would make sense to make flatpak default to --user installation there, without forcing the user to remember and provide this option every time. Even worse: not every time, but depending on VM type. While QubesOS-specific part (detecting what should be the default) would be on our side, an interface to configure it would make it easier.

Right now the only option (I know of) is to add a wrapper script that:

• parse command line
• add --user/--system option to relevant commands

This is very fragile solution, as it needs to follow flatpak options changes, avoid conflicts (for example when the user provide such option too) etc. Also, I'm not sure if it will work if flatpak app is installed through GUI like GNOME Software.

[TingPing]

As a matter of example, 'http_proxy' variable could be set differently for flatpak instead of using the global one.

Flatpak applications should use the xdg-desktop-portal to query proxy information. On the host that portal could respect whatever proxy settings you want.

[marmarek]

The point is to configure proxy for flatpak itself (downloading applications), not flatpak application.

[TingPing]

Ah misunderstanding.

[matthiasclasen]

The more we push into config files, the less predictable the behavior is.

[marmarek]

I see your argument, also in #2887, but I think it is flawed. While --assumeyes indeed may not be good fit for config file, system specific settings definitely are. After all, you don't expect users to for example provide full repository url all the time, and save it in a config, no?
My goal here is smooth user experience. Having to type flatpak install spotify is ok UX. Having to type some_var=value flatpak install --this --that --and-something-else spotify definitely is not, especially when those options are constant on given system, and the command would fail without them.

You suggested a wrapper script in #2887. This will work, but I think it is more confusing. For example, flatpak install --help would be inaccurate if --user is provided by a wrapper script.

Just to be clear, we're happy to implement this feature, but want to discuss what would be acceptable option. We want to use it for default configuration at distribution level.

[dustymabe]

It would make sense to make flatpak default to --user installation there, without forcing the user to remember and provide this option every time.

Totally agree. On my system I explicitly disabled the system repo by clearing it our and making /var/lib/flatpak/repo an empty file (so the repo won't get created again). However that means flatpak run which By default, flatpak will look for the application or runtime in all per-user and system installations will fail because it tries the system repo first:

error: While opening repository /var/lib/flatpak/repo: /var/lib/flatpak/repo: opendir(/var/lib/flatpak/repo): Not a directory

but it means that all my .desktop files won't use --user because they don't have it embedded in them. One example:

$ grep Exec /var/home/dustymabe/.local/share/flatpak/exports/share/applications/org.mozilla.Firefox.desktop 
Exec=/usr/bin/flatpak run --branch=stable --arch=x86_64 --command=firefox --file-forwarding org.mozilla.Firefox @@u %u @@
Exec=/usr/bin/flatpak run --branch=stable --arch=x86_64 --command=firefox --file-forwarding org.mozilla.Firefox --new-window @@u %u @@
Exec=/usr/bin/flatpak run --branch=stable --arch=x86_64 --command=firefox --file-forwarding org.mozilla.Firefox --private-window @@u %u @@

If I could set an evinronment variable for my user session then any invocations of /usr/bin/flatpak would appropriately use --user without me having to track down every time the CLI gets invoked to fix it.

[matthiasclasen]

Totally agree. On my system I explicitly disabled the system repo by clearing it our and making /var/lib/flatpak/repo an empty file

So you mutilated the flatpak installation, and you are not happy that flatpak complains about that?!

[dustymabe]

So you mutilated the flatpak installation,

I explicit don't want a system wide install. It's not simply good enough to remove it because flatpak will create it again, so I had to do this, yes.

and you are not happy that flatpak complains about that?!

I would be ok if it complained about it with a warning message and continued on to the user installation, but it doesn't. It errors out. I should probably open a bug requesting it do that.