A path to xdg-utils2 in python

[Simon Lees]

On 01/03/2019 19:53, Bastien Nocera wrote:
> On Fri, 2019-03-01 at 19:11 +1030, Simon Lees wrote:
>>
>> On 28/02/2019 20:36, Bastien Nocera wrote:
>>> Hey,
>>>
>>> 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.
>>>
>>
>> I still plan to use the current CI tests but I see them being rather
>> limited compared to the system level testing I can do in openqa which is
>> far more useful. For example across 4-5 different desktops I can call
>> xdg-terminal and check that the same terminal is launched, or can check
>> that the right authenticator is used for xdg-su and that authentication
>> succeeds or fails as it should. It can also do things like
> 
> Like what?
> 
> You can run OpenQA in the upstream CI as well.
> 

Being able to run it is one thing, being able to maintain it is a 
different issue though, everytime desktops are updated there are small 
changes that tests need to be adapted, sometimes people get crazy ideas 
and go we should change the default font or or a desktops theme, then 
lots of tests need to be updated. I don't have time to maintain all the 
tests for different desktops in the xdg-utils CI so it would just end up 
mostly failing due to unrelated issues, however there are a number of 
people that help maintain openSUSE's openqa instance including the 
maintainers of the various desktops so the amount of effort to maintain 
tests there is significantly lower. I believe other distro's are 
starting to also use openQA so potentially I can add tests there as 
well. I can probably also run xdg-utils git master against the tests on 
a semi regular basis manually but I don't think I could automate it into 
the xdg-utils

>>>> 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.
>>
>> Well whenever the week comes I will already have a plan and
>> everything
>> layed out and i'll know what I can pull in from existing python
>> libraries. So I should be able to just sit down and write. Many of
>> the
>> tools are pretty simple although they have alot of boilerplate code
>> and
>> the complicated stuff which is the desktop and mime handling will
>> hopefully mostly be coming from another already written library.
>>
>> I'm not aiming to get everything done in that week but i'd like to
>> get
>> it to a point where the framework is there so I or other people can
>> grab
>> and do a small chunk thats still missing.
>>>> 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.
>>
>> Unfortunately it would still be nice if xdg-utils didn't require
>> libgtk
>> to be installed I know the number of systems these days that doesn't
>> have it are minimal but it would still be nice.
> 
> Those tools don't use GTK.
> 
I'm aware that they don't currently, but to use the implementations via 
gobject-introspection i'm guessing that it would require some of those 
dependencies, I have no idea how GTK is split up these days and whether 
Glib and GIO are part of it but when I was mentioning this I was 
referring to GTK and its related libraries.

>> I haven't really had anything to do with flatpack or any of the
>> other
>> sandboxing approaches are they still able to see / call
>> /usr/bin/xdg-open? if so doing the dbus calls from python won't be
>> hard
>> in fact the version of xdg-open I have on my machines has an
>> open_flatpak function which makes the following dbus call
>>
>> gdbus call --session \
>>           --dest org.freedesktop.portal.Desktop \
>>           --object-path /org/freedesktop/portal/desktop \
>>           --method org.freedesktop.portal.OpenURI.OpenURI \
>>           "" "$1" {}
>>
>> Outside of flatpak it still has alot of uses, I think some of the
>> smaller desktops might even still be using it with a desktop file as
>> the
>> path to launch applications.
> 
> I'm sorry, but I have no idea what those comments correspond to.
> 
> But you seem set on wanting to rewrite xdg-utils in Python. Good luck.
> 
Well I did consider some other alternatives I could use C++ with boost, 
I dislike using the C and C++ standard libraries for string handling 
enough that I don't think the result would be any better then posix 
shell. I could do it really comfortably and cleanly using Qt's core 
libraries but I don't think xdg-utils should require Qt in the same way 
I don't think it should require gio. I think that python makes more 
sense then perl because more people in general myself included find 
python code easier to maintain. A python replacement has also been 
discussed on this list before, if anyone has other suggestions for a 
language i'm open to suggestions but atm python makes the most sense.

Cheers

-- 

Simon Lees (Simotek)                            http://simotek.net

Emergency Update Team                           keybase.io/simotek
SUSE Linux                           Adelaide Australia, UTC+10:30
GPG Fingerprint: 5B87 DB9D 88DC F606 E489 CEC5 0922 C246 02F0 014B