flatpak
flatpak copied to clipboard
flatpak
[Feature request]: Suggestion for how to implement CLI tools
Checklist
- [X] I agree to follow the Code of Conduct that this project adheres to.
- [X] I have searched the issue tracker for a feature request that matches the one I want to file, without success.
Suggestion
After reading this https://github.com/flatpak/flatpak/issues/1188 I had some ideas on what an implementation could look like and just wanted to share them with anyone who is interested.
The main concern seemed to be how to handle multiple flatpaks being able to implement their own commands that could potentially conflict and over 'security' of apps mapping commands across a system willy-nilly.
So, I have some suggestions, in the form of examples of how the solution could look:
Installing an app - Normal install, no CLI commands
> flatpak install org.PythonSoftwareFoundation.Python
Lets say we wanted to turn Python into a Flatpak. Obviously this will require CLI tools. A normal installation would look like this, no change to the command yet.
Running a command for the first time
Attempting to run a Hello World python script...
> python hello_world.py
Outputs a choice for a list of Flatpaks that could be associated with that command:
Flatpaks Available
===============
Apps available that implement the 'python' command:
> * org.PythonSoftwareFoundation.Python
(Use up/down keys to choose, and press enter to confirm, press esc to cancel.)
After choosing a Flatpak, you can choose to either use this Flatpak for this command 'just this once' or 'always'.
Run 'python' command with 'org.PythonSoftwareFoundation.Python':
> * Just this once
* Always
(Use up/down keys to choose, and press enter to confirm, press esc to cancel.)
Note: You can manage this setting later with:
flatpak commands python
If you choose 'Just this once' then the next time you run the command, you will be presented with the same choice. If you choose 'always', the preference will be remembered and the command mapped automatically.
Hello World
After making a choice, the command runs. If you picked 'always', the next time you run the command, the flatpak version of Python will automatically be used.
> python hello_world.py
Hello World
Installing an app - Automatic CLI Install
Some Flatpaks might expose dozens of commands, and the user may want every command to be exposed and set as the default during install to save time for trusted apps.
> flatpak install org.PythonSoftwareFoundation.Python --auto-set-commands-as-default
The above is equivalent to installing an app, running each command it provides for the first time, choosing the app ID, and choosing 'always'.
When Multiple Applications Provide The Same Command
What happens when multiple apps provide the same commands?
> flatpak install org.Mozilla.Firefox
> flatpak install org.Bogus.Firefox
> firefox
The same confirmation comes up as before, this time with multiple apps to choose from.
Flatpaks Available
===============
Apps available that implement the 'firefox' command:
> * org.Mozilla.Firefox
* org.Bogus.Firefox
(Use up/down keys to choose, and press enter to confirm, press esc to cancel.)
Note: You can manage this setting later with:
flatpak commands firefox
When multiple apps all provide the same command, the user will see a list of the apps with their full ID names. The user can choose one to use this once, or always, or cancel.
Finding Out Which Flatpak is Assigned To A Command
> flatpak commands python
'python' command is set to 'org.PythonSoftwareFoundation.Python'
Flatpaks avaliable:
* org.PythonSoftwareFoundation.Python
To reset this command's setting, run flatpak commands python --reset
Q/A
1. "Don't want a Flatpak to be able to install system commands willy-nilly" This UX avoids that, the user is made aware of which Flatpak is running a command and must confirm the choice, with an option to remember the preference if they are confident and trust the app.
2. "What happens when multiple Flatpaks implement the same command?" With this approach, the user can have multiple Flatpaks installed that implement the same command, and choose which one they want associated with each command.
3. "How can this work on a technical level?" Apps could provide as some kind of configuration file (even a simple commands.json text file) a list of commands they implement and how to map those commands to binary executables within the Flatpak.
When Flatpak installs an app, it can take note of which apps implement which commands, and retain a list of available commands globally from all Flatpaks.
Flatpak could have a folder location added to the system's PATH, such as flatpak/bin, where symlinks to all of these commands could be created to represent each available command.
So lets say you install org.PythonSoftwareFoundation.Python, which has a command 'python. Flatpak could create a symlinked file flatpak/bin/python. This could be a symlink to flatpak or some other flatpak related executable that can intercept that command, and provide the above described functionality.
Flatpak is not really designed for this use-case: it is designed for GUI apps, analogous to what the term means on (for example) Android or iOS, so implementing the proposed prompt is unlikely to be a priority for any of the maintainers. So the most likely scenario where this happens is that someone (either you or someone else who particularly wants this) provides a pull request.
However, even if a ready-to-merge PR was provided, it's possible that maintainer consensus would be that this feature isn't wanted, because Flatpak is focused on GUI apps and does not aim to be the only software installation tool that you will ever need. It's OK for use-cases outside Flatpak's scope to need something that isn't Flatpak, for example Toolbx. There is room for more than one software installation framework in the world, and the more we spread Flatpak's limited developer/maintainer effort across more use-cases, the worse we will be able to support each of those use-cases.
Having this in the flatpak(1) CLI is also only a half-solution, because the flatpak(1) CLI is not meant to be the only way to install a Flatpak app - in fact, in an ideal world, the flatpak(1) CLI would only be for advanced users and noninteractive installations. The primary user-friendly way to install Flatpak apps should be a user interface like GNOME Software or KDE Discover, which is linked to the libflatpak shared library or loads a plugin that is linked to libflatpak. So, if the proposed design was implemented, there would need to be a C API in libflatpak with which GUIs like GNOME Software and KDE Discover could discover what commands exist, get user consent for adding them to the PATH, and make it happen, without having to hard-code implementation details like the exact paths involved into the GUI app.
CLI tools as Flatpak apps will often also not be as useful as you might imagine, because Flatpak's sandboxing will interfere with the tool's ability to access files from outside the sandbox in the expected CLI way, so the app manifest would have to have extremely broad (therefore dangerous) permissions. I suspect that in many cases the required permissions for the CLI tool's expected functionality would make it effectively un-sandboxed (capable of carrying out a sandbox escape and executing arbitrary code on the host) which is not something that we want to encourage.
And, listing CLI tools in an "app store" UI like GNOME Software or KDE Discover would make it harder for new users who are not familiar with a CLI interface to find apps that work in the way that they expect.
Flatpak could have a folder location added to the system's PATH, such as flatpak/bin, where symlinks to all of these commands could be created to represent each available command.
This already exists, it's /var/lib/flatpak/exports/bin or ~/.local/share/flatpak/exports/bin (it isn't added to the PATH by default, but users can add it to the PATH if they want to). However, because of the security and app-identity concerns already raised in #1188 and elsewhere, it's currently populated with symlinks whose names match the full app ID.
Use up/down keys to choose, and press enter to confirm, press esc to cancel
This is describing a "TUI" (like a GUI, but in a terminal), which is much more complicated than a simple prompt and in practice requires additional dependencies (ncurses or equivalent). This is very unlikely to be implemented or merged. If the Flatpak CLI gains any additional prompts, they are more likely to be in the style of the prompts that already exist, where you type the number associated with a choice and press Enter.
If someone wants to write a TUI that uses ncurses or similar to provide a friendlier interactive terminal frontend to Flatpak app installation, then they are very welcome to do so - but to avoid putting extra load on Flatpak's maintainers, it would be better as a separate project, linking to libflatpak in the same way that GNOME Software and KDE Discover do. This would be analogous to the way that in Debian/Ubuntu, the aptitude TUI links to the same libapt library that the apt tool does, but it is not part of apt, and the apt maintainers are not required to maintain or support aptitude.
