Taking over xdg-utils

[Simon Lees]

On 8/30/20 6:53 AM, Piotr Karbowski wrote:
> Hi Simon,
> 
> On 26/08/2020 09.27, Simon Lees wrote:
>> I am also interested in this, there are simply to many bugs related to
>> shell quoting behavior etc that break something else when they get
>> fixed. Unfortunately I have been moved into a different team at work for
>> the next few months and don't have alot of time atm.
>>
>> When I did some initial research into the idea I planned to split the
>> mime stuff out of pyxdg into a python-mime library and use that as well
>> as creating a separate python library for things like
>> desktop_file_to_binary etc Unfortunately I didn't get past the design stage.
>>
>> While I don't have much time in the next 6 months once you upload the
>> code i'll happily review it and help test it on openSUSE.
> 
> Will post to list with link to repository once at least basic feature
> parity with current xdg-utils is achieved.
> 
> My goal is to create a drop-in replacement for xdg-utils, while greatly
> simplifying the logic. For example, xdg-open uses xdg-mime, and xdg-mime
> have whole logic to choose what tool it should use to query for
> mimetype, if there's kde, it will use kmimetypefinder, if there's gnome
> it will use gio and fallback to gvfs-info, if it fail to detect DE, it
> will use mimeinfo written in Perl instead.
> 
> For this route the new xdg-mime will just use python-magic (bindings to
> libmagic) regardless of what DE is running, as I really see no benefit
> in using DE specific tools to query for mime, it will only result in
> fragmentation and issues with reproducing bugs, as there's multiple code
> paths.
> 
> After you mentioned pyxdg I looked into it, from what I see it uses
> rox-lib2's mime.py to query shared-mime-datebase, but in this case, I
> think I will just stick to python-magic (libmagic) instead, as it seems
> to be widely used already in other projects.

I also share others concerns about this, and if its going to be a
blocker for other people adopting the new python version then I think
its worth reconsidering.

The aim of having just one codepath that works with the mime database in
a compliant way makes sense, my aim was to first have standards
compliant python libraries for handling things like mime and desktop
files that would also be useful for writing a xdg-utils replacement as
well as other applications / scripts. If python-magic is already doing
that I see no point in re inventing the wheel, If it is not and they are
unwilling to implement a "compliant mode" then i'm back to being inf
avor of creating python-mime from the old pyxdg codebase.

What I'm less sure about is re-implementing  all of say xdg-terminal or
xdg-su in python, in these cases it might make more sense to replace the
"complex" logic such as desktop_file_to_binary with helper scripts
written in python living in libexec and leave much of the rest in bash,
I think it would be more complex to implement many parts of those
scripts in python then it is in bash. It might also make the testing /
migration path smoother.

> If you have any other suggestions, comments or information, please let
> me know, I plan to have a working PoC within few weeks (by working I
> mean something that will work on my Gentoo for daily usage. :))
> 
> -- Piotr.

Yeah unfortunately for me I have to end up with working without
regression on the 8-9 different desktops you can find in openSUSE, which
includes making sure there various gui's for interacting with the mime
database also still work.