A path to xdg-utils2 in python

[Simon Lees]

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,
> Thomas

Hi,

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