Is there a more streamlined way to run flatpaks through terminal?

For example VS Code usually allows you to run a command through terminal like

code ~/src/my-project

but when installed via flatpak I must do

flatpak run com.visualstudio.code ~/src/my-project

I was able to shorten it up by putting an alias in my bashrc file like this

alias code='flatpak run com.visualstudio.code'

That’s okay for one or two programs, but now that I’m running silverblue I’m wondering if there is a better way to do this. I was wondering if it’s possible for a flatpak to export/provide this alias to the host so manual intervention isn’t necessary when installing. Much like in JavaScript how you can export a function as a third part in your module and someone (the host in this case) would know based on some sort of standard that it should include the alias

Not an exact solution to your query but:

You could add /var/lib/flatpak/exports/bin to your path and run VSC by issuing com.visualstudio.code


What, so shorter than flatpak run <flatpakapp>?

To a large degree, but not entirely the goal. I remember running OpenSuse way back and I was developing in Java at the time. If you had multiple Java SDKs, you could switch which javac binary would be executed pretty easy using update-alternatives if I remember correctly. I was thinking something along those lines to manage large amounts of installed software through flatpaks.

Say I remove org.mozilla.Firefox with flatpak. I may have added an alias firefox that pointed to that flatpak a year ago, and now have an alias that points to a nonexistent flatpak. I then install org.mozilla.firefox (one from flathub has different case). Well unbeknownst to me, as a user I may try to run firefox It would be confusing because bash autocomplete would work, yet the command would not run. Sure I would realize at that point pretty quickly from the error that it is somehow pointing at the old firefox and I could hunt it down. But as more programs are installed in that bashrc file it starts looking “messy”.

I didn’t actually think of flatpak potentially having a feature itself, was thinking more along the lines of a wrapper that would have hooks anytime flatpak installs/removes a flatpak it would automatically provide/remove the symlinks to relevant binaries, assuming it’s not an alternative, at which point would ask which one to use.

When I created this question I didn’t remember what update-alternatives was called though. I may make a little program to do what I’m thinking now that I remember that’s a thing.