Use UDisks to find mounted filesystems on Linux #2683
Conversation
|
Thanks, and sorry for the late response! It looks like |
Great! I was thinking I would attempt to use Udisks before falling back to |
e2e3737 to
4e4e8a9
Compare
|
@aivarannamaa I've got this working now. I've tested it in the Flatpak and verified that flashing a Raspberry Pi Pico in the UF2 dialog works without issue. It actually works better than Thonny's current behavior on my system since the |
This should generally work better on Linux than using the mount command directly. UDisks is the utility that all major Linux desktop distributions use to handle mounting filesystems in userspace. UDisks is accessible through a D-Bus API on the system bus. D-Bus is complex and requires adding a dependency on a Python library for handling asynchronous communication with the bus. I chose dbus-next since it is actively developed, modern, and doesn't require a glib main loop. Since Thonny is not a Gtk application, it makes more sense to use native Python async functionality instead. Inside a Flatpak, it's necessary to use UDisks via the D-Bus API to mount and check mounted filesystems. The Flatpak sandbox prevents mounting otherwise and does not supply a mount command with the runtime.
Add XML files for D-Bus introspection. Provide synchronous wrapper function to list volumes. Check for volumes with Udisks on Linux before resorting to mount. Ensure that only devices with "filesystem" usage are listed. This excludes device nodes like /dev/sda when we only care about filesystems which are on partitions like /dev/sda1. List volumes according to their detection times. This is a convenience for the user. Most recently detected devices are listed first.
This prevents unnecessary errors from the mount command not being found when Udisks is available.
This avoids potential issues with the license header from the XML file taken directly from the UDisks project. Additionally, place the DBus XML files in a dedicated `dbus` subdirectory instead of using the res directory.
b327569 to
312ccaf
Compare
|
Should we also consider adding support of xdg desktop portals ?? |
I believe Tcl/Tk already uses the native file-chooser dialog when selecting a file, which is why it is possible to select files to open and save when the Flatpak sandbox is completely isolated. However, for the Flatpak I've allowed permissions to the user's home directory and the default locations for mounted media. This is so that paths to files are consistent with a person's directory layout on their machine and to allow access to mounted devices. Having Python files individually opened and mounted to arbitrary locations inside the Flatpak makes it untenable to develop anything in Thonny larger than a single file. Most Flatpaks of developer tools grant even greater permissions by default for the same reason. I don't think there is an XDG desktop portal which allows opening directories either, which would be the primary requirement to allow the sandbox to be restricted further. I'm not sure which XDG desktop portals you have specifically in mind, but I've assumed so far you were referring to file access. Was there something more specific to this PR you had in mind or were you asking more generally? |
What i was saying is that although thonny uses xdg portals for file access in flatpaks due to the default mechanism of flatpak being built around xdg portals ,by default thonny does not uses xdg portals since in snap sandbox it continues to use the tk one, this is even after forcing it to use portals, thonny always uses its internally built less interactive yet working tk dialogs to access files, so i was thinking if we somehow force thonny to use xdg portals as its default globally, this was a suggestion or maybe a general question... |
Ahh, I think that's an aside from this PR, but do you have |
I will try pushing new build with staging zenity, thanks for the tip as for the pr the snap thonny variant has already been registered for dbus by me with the id :- org.thonny-ide.thonny, but i later commented the dbus config in the snap yaml since i came to knew that thonny doesnt use dbus, so if dbus support lands in thonny in future i will be able to easily push that release through snap. |
|
Thanks! At first try I got a segfault crash on Ubuntu 22.04, when opening the back-end selector menu (which looks for volumes looking like MicroPython or CircuitPython UF2 installation volumes). I couldn't reproduce it later, though. I'll leave it as is for now, but if I experience this crash again, I'll make |
* Enhance esptool GUI, thonny#2707 * Windows fixes for esptool GUI, thonny#2707 * More forgiving image analysis for esptool GUI, thonny#2707 * black * Misc fixes for esptool GUI, thonny#2707 * Use UDisks to find mounted filesystems on Linux (thonny#2683) * Use UDisks to find volumes on Linux This should generally work better on Linux than using the mount command directly. UDisks is the utility that all major Linux desktop distributions use to handle mounting filesystems in userspace. UDisks is accessible through a D-Bus API on the system bus. D-Bus is complex and requires adding a dependency on a Python library for handling asynchronous communication with the bus. I chose dbus-next since it is actively developed, modern, and doesn't require a glib main loop. Since Thonny is not a Gtk application, it makes more sense to use native Python async functionality instead. Inside a Flatpak, it's necessary to use UDisks via the D-Bus API to mount and check mounted filesystems. The Flatpak sandbox prevents mounting otherwise and does not supply a mount command with the runtime. * Smal fix for esptool GUI, thonny#2707 * Update CircuitPython links * CircuitPython 8.1 stubs * Small fixes for flasher dialogs, thonny#2707 * Update CREDITS.rst * Restore MicroPython completions in the shell, thonny#2467, thonny#2419 * Rely on Jedi's builtins.pyi * Fix MicroPython builtins completion * Consider modules in project directory when completing * Update MP links * Refactor MP link collection * Update MP links * Require backend ACK before sending initial input * Prepare for Python 3.12 * Update copyright year * More Python version range fixes * Simpler Python version display * Move PROCESS_ACK * Simpler Python interpreter selection * Ensure Thonny's backends don't get confused by other installations, thonny#2616 * Alternative approach for thonny#2616 * Restore user site-packages for CPython backend, thonny#2616 * remove temp logging * Experiment with module conflict detection, thonny#384 * Fixes for regressions caused by 4104729 --------- Co-authored-by: Aivar Annamaa <aivar.annamaa@gmail.com> Co-authored-by: Jordan Williams <jordan@jwillikers.com>
This should generally work better on Linux than using the mount command directly. UDisks is the utility that all major Linux desktop distributions use to handle mounting filesystems in userspace. UDisks is accessible through a D-Bus API on the system bus.
D-Bus is complex and requires adding a dependency on a Python library for handling asynchronous communication with the bus. I chose dbus-next since it is actively developed, modern, and doesn't require a glib main loop. Since Thonny is not a Gtk application, it makes more sense to use native Python async functionality instead.
Inside a Flatpak, it's necessary to use UDisks via the D-Bus API to mount and check mounted filesystems. The Flatpak sandbox prevents mounting otherwise and does not supply a mount command with the runtime.
Fixes flathub/org.thonny.Thonny#153, #2650, and #2426.
Probably fixes #2649.