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
_______________________________________________
xdg mailing list
xdg@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/xdg
