My idea was that in addition to command: blah in the manifest, we also add commands: ['blah', 'blah', 'blah'] so that additional executable entry points can be added to Flatpaks. Then in addition to the app ID wrapper scripts written out here https://github.com/flatpak/flatpak/blob/main/common/flatpak-dir.c#L8944 we would also write app.id-blah wrappers with each of the commands.

Then we are able to add the native messaging host path to the list at https://github.com/flatpak/flatpak/blob/main/common/flatpak-dir.c#L7984 and - provided the binary name is one of the commands above - substitute the executable name for the wrapper script which is added above. Note that the standard does not allow passing arguments to these native host binaries, which is why we must go via the wrapper script. Personally I believe that having a general-purpose multiple binary export mechanism is more useful for other cases than having a special-case just for native messaging hosts.

Unsolved so far in this plan is how can the browsers discover the exported native messaging hosts, which will be in a non-standard path (on XDG_DATA_DIRS, but not necessarily checked by the browsers or the web extension portal)?

Then in addition to the app ID wrapper scripts written out here https://github.com/flatpak/flatpak/blob/main/common/flatpak-dir.c#L8944 we would also write app.id-blah wrappers with each of the commands.

If I remember correctly we allow dashes in the last dot-separated segment of an app ID, so they might have to be app.id.blah to make them collision-free.

Personally I believe that having a general-purpose multiple binary export mechanism is more useful for other cases than having a special-case just for native messaging hosts.

A good concrete use-case for this might be that com.valvesoftware.Steam contains both steam-wrapper and steamcmd-wrapper entry points.

Are you saying that com.valvesoftware.Steam should additionally export .../flatpak/exports/bin/com.valvesoftware.Steam.steamcmd (or ...Steam-steamcmd in your proposed naming), which would have behaviour equivalent to flatpak run --command=steamcmd-wrapper com.valvesoftware.Steam?

Maybe it should also export .../flatpak/exports/bin/com.valvesoftware.Steam.steam, which would be equivalent to flatpak run com.valvesoftware.Steam with the default command steam-wrapper, but more explicit?

Or, they could be named like com.valvesoftware.Steam+steamcmd using a separator that isn't allowed in app-IDs (for which I think +, :, , and maybe = and @ are the only options that aren't going to be annoying to use from a shell).

A good concrete use-case for this might be that com.valvesoftware.Steam contains both steam-wrapper and steamcmd-wrapper entry points.

Are you saying that com.valvesoftware.Steam should additionally export .../flatpak/exports/bin/com.valvesoftware.Steam.steamcmd (or ...Steam-steamcmd in your proposed naming), which would have behaviour equivalent to flatpak run --command=steamcmd-wrapper com.valvesoftware.Steam?

👍

Maybe it should also export .../flatpak/exports/bin/com.valvesoftware.Steam.steam, which would be equivalent to flatpak run com.valvesoftware.Steam with the default command steam-wrapper, but more explicit?

I'm relaxed on whether we effectively prepend command at commands[0]. It does have the advantage of if you are trying to autocomplete shell commands from the exported wrapper scripts, the "obvious" one is also always there.

Or, they could be named like com.valvesoftware.Steam+steamcmd using a separator that isn't allowed in app-IDs (for which I think +, :, , and maybe = and @ are the only options that aren't going to be annoying to use from a shell).

Yeah maybe a + is safer to avoid aliasing. You just know someone will export a command named desktop and the universe will implode. 🤣

My idea was that in addition to command: blah in the manifest, we also add commands: ['blah', 'blah', 'blah'] so that additional executable entry points can be added to Flatpaks

At the flatpak/flatpak level, there is no manifest, only flatpak build-finish --command=COMMAND. To prototype this, it would be enough to add --export-command=steamcmd (or whatever new CLI syntax is chosen by the implementor) to the finish-args in the manifest. Anything beyond that would just be syntactic sugar provided by flatpak-builder.

With Steam's use case in mind, it would maybe be best to have syntax like --export-command=[NAME=]COMMAND, where COMMAND is assumed to be in /app/bin (or in the sandbox's PATH?) if not absolute, and NAME defaults to the basename of COMMAND; so a typical simple app like GNOME Recipes could have --export-command=gnome-recipes, but Steam could have --export-command=steam=steam-wrapper and --export-command=steamcmd=steamcmd-wrapper.

Hmm... I'm a little skeptical here about whether we really need the renaming. Mostly because it causes me to go back and question the behaviour of automatically exporting the --command, because it doesn't have the opportunity to be renamed. Inspecting the bin/ dirs of the Flatpaks I have installed, overwhelmingly the binaries are named "normally" in bin, and even those with wrappers manage to give the wrapper the expected name, and the underlying binary is named or located differently (be it foo.bin, or /app/extra/..., or /app/appname/appbin, etc).

Yes, I can see an argument that the Steam Flatpak should rename the underlying executables provided by Valve to steam.real and steamcmd.real or something (or move them to a directory off the PATH, or similar), and then rename its steam-wrapper and steamcmd-wrapper to steam and steamcmd (possibly with a compatibility symlink).

Anything left to do here, or should we merge this?