A path to xdg-utils2 in python
sflees at suse.de
Fri Mar 1 04:49:53 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.
> Best wishes,
Certainly my initial thoughts before looking at what already exists was
to create one library related to desktop file handling and another for
handling mimetypes, because those parts are probably useful for other
programs, then I was going to put all the other code shared between the
various tools in an "Internal" library.
So if you agree this is a good way forward why don't we work towards a
series of libraries to replace the old one then, that way people can
migrate as they choose.
I'll get in touch when I'm closer to starting to writing code. It would
be good to have a solid plan for what should be replaced, what should be
reused / rewritten / dropped before I start.
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