Re: A path to xdg-utils2 in python
Simon Lees <[email protected]>
| Newsgroups | gmane.linux.xdg.devel |
|---|---|
| Message-ID | <[email protected]> |
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 _______________________________________________ xdg mailing list [email protected] https://lists.freedesktop.org/mailman/listinfo/xdg