A path to xdg-utils2 in python
sflees at suse.de
Thu May 30 14:08:24 UTC 2019
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
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.
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
More information about the xdg