A path to xdg-utils2 in python

[Simon Lees]

Hi,

On 28/02/2019 20:07, Thomas Kluyver wrote:
> Hi Simon,
> 
> On Thu, Feb 28, 2019, at 12:08 AM, Simon Lees wrote:
>> 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.
> 
> As the not very active maintainer of PyXDG: much of the package is written in ways I would avoid for new code - e.g. it has its own ini file parsing instead of using the standard library configparser module. I'm wary of changing it because it's been around for a long time and people could be relying on all kinds of implementation details. But I wouldn't necessarily encourage you to use it for new code.
> 
> If there's useful functionality in there, by all means make use of it. But you might be better off extracting and refactoring any code you want, either as internal modules for xdg-utils2 or as separately packaged parts. I can probably find some time to help with this if you like.
> 
> When I first read your email,  I thought about a parallel 'pyxdg2' project to produce a modern version of that code without compatibility constraints. But on further thought, I don't think it necessarily makes sense to bundle together the different functionality that's in PyXDG. Historically, the limitations of the Python packaging tools pushed us towards fewer, bigger packages incorporating disparate functionality, and PyXDG is exactly that. Now the tools have improved, it's more practical to have more focused packages - e.g. maybe desktop file handling could be its own package.

In a couple of weeks i'll have 30ish hours allocated to make a start on 
this, my initial plan is to rewrite the "pyxdg" desktop file classes as 
"xdgdesktop" (i'm open to other naming suggestions) keeping the same API 
where possible but basing the class off configparser I will probably 
also add the desktopfile_to_binary and binary_to_desktopfile functions 
that are commonly used in the xdg-utils shell scripts as well. Having 
this functioning as a standalone library in a "beta" state that people 
could start using complete with updated test cases seems like a easily 
reachable goal. I guess another question that should be asked is should 
we drop anything thats no longer being used? I'm not especially familiar 
with what and how the KDE specific stuff is used and whether it is still 
relevant.

Then the plan is to move onto xdgmime again I think its probably worth 
splitting all the mime handling out into a separate library (although 
i'm open to discussion), at a first glace the existing mime code seems 
reasonable although you as the author might have ideas about things that 
should change. I plan to extend the library to cover everything that the 
xdg-mime script currently does which will include stuff like setting and 
getting the default mimetypes etc, I guess these functions could go into 
a mimedatabase module.

Beyond that I don't think it makes sense to split the other modules out, 
but I will tidy them up for example i'll drop the use of inifile and 
require python 3.3 so that some of the other work arounds can be 
removed. Beyond that i'll also add support for some of the common 
functions in the xdg-utils scripts such as detecting if a graphical 
server is running and detecting the desktop environment.

After that the process of rewriting a lot of the command line tools 
shouldn't be too hard but I don't think i'll get there during the week I 
have this time, its something I will slowly do after.

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