A path to xdg-utils2 in python

[Bastien Nocera]

Hey,

On Thu, 2019-02-28 at 10:38 +1030, Simon Lees wrote:
> Hi,
> 
> For those who don't know me, I am currently the xdg-utils maintainer
> for 
> SUSE / openSUSE.
> 
> Given that SUSE is in a year where where SUSE doesn't have any major 
> releases scheduled I have a bit of extra time, I am also sick of
> fixing 
> errors with desktop file / mime handling in posix shell. People on
> this 
> list have in the past discussed the idea of rewriting xdg-utils in 
> python oneday if someone has the time, I asked my manager nicely and
> I 
> now have the time. As such i've developed the very rough plan below
> that 
> i'll work on carrying out if there's a general consensus here that
> its a 
> sensible way forward. I have been allocated a couple of hours a week
> to 
> work on this.

While I share your hate for the xdg-utils codebase, a couple of
comments below.

> Stage 1: Implement regression tests for the existing xdg-utils in 
> openSUSE's openqa instance, openqa.opensuse.org there is already
> general 
> testing for most desktops here but i'm planning to extend these
> tests 
> with more xdg-utils specific tests.

The freedesktop.org GitLab has a CI, you should add and run the tests
upstream, against the current implementation, if you want to be sure to
minimise the behavioural differences.

dbusmock is a very useful tool to use if you want to implement the
server-side of some of the tools for testing.

> Stage 2: SUSE has a hackweek (https://hackweek.suse.com) once a year 
> where SUSE employees get a week to work on whatever they feel like.
> The 
> dates for this years have not been announced yet but my plan is to
> spend 
> most of that week doing the bulk of the rewrite.

You're probably underestimating the amount of work required.

> Stage 3: Spend 2 hrs a week implementing the remaining code.
> 
> Stage 4: Submit a "beta" version into openSUSE Tumbleweed, given
> there 
> will already be regression tests in openqa by the point its accepted
> I 
> should be pretty confident that most of the major issues should have 
> been found and fixed.
> 
> Design:
> Where ever possible i'm currently planning to use as much of the 
> existing pyxdg libraries especially for handling all the mime /
> .desktop 
> file handling.

For what it's worth, there's also an implementation for the .desktop
and mime handling available in GLib, some of which are available
through "gio mime" or "gio open". Those APIs are also usable from
Python through gobject-introspection.

The current xdg-utils are unusable inside a sandbox, which is why xdg-
open and xdg-email were replaced by portal clients:
https://github.com/flatpak/flatpak-xdg-utils/tree/master/src

This might be something to keep in mind.

The other thing to keep in mind is all the tools in this list that
aren't xdg-email or xdg-open still need to be reimplemented, or at
least assessed.

You can use Debian's codesearch to find some of the uses:
https://codesearch.debian.net/search?q=xdg-desktop-icon&perpkg=1

My own assessment would be:
$ rpm -ql xdg-utils | grep bin
# There are better installation methods than this, remove
/usr/bin/xdg-desktop-icon
/usr/bin/xdg-desktop-menu
/usr/bin/xdg-icon-resource
# Replace
/usr/bin/xdg-email
/usr/bin/xdg-open
/usr/bin/xdg-mime
# Only works with X11, nuke
/usr/bin/xdg-screensaver
# Does the same thing as xdg-mime for x-scheme-handler,
# remove, or replace with xdg-mime code
/usr/bin/xdg-settings

Whether with my Fedora, Flatpak, or GNOME hat on, my course of action
would be to extend the above mentioned "flatpak" versions (xdg-email
and xdg-open) to work outside the sandbox, and add an xdg-mime
implementation. And have that replace the upstream xdg-utils.

Cheers