Taking over as maintainer for `pyxdg`?

[elsiehupp]

I mentioned this in a pull request over at the pyxdg repository. The problem is that pyxdg is effectively EOL while also still being the official/reference implementation for a number of XDG standards in Python.

My reasoning for suggesting that you take over as the maintainer for pyxdg is that you are actively maintaining the most popular Python XDG implementation and that you already control the xdg namespace on PyPI. Because your package is called just xdg rather than more specifically xdg-base-directory, it would actually make sense for the package to be a "kitchen sink" of various XDG reference implementations rather than just the one.

If this is something that interests you, you would probably be able to get Thomas Kluyver to set you up with an official Freedesktop repository mirror on their Gitlab and (if you wanted) add you to the Freedesktop organization on GtiHub so that your repository could have a github.com/freedesktop URL. (I don't know what the logistics would be.)

(Yes, I know that you would probably want to substantially rewrite pyxdg in order to combine it with your module, so this would be more about "carrying the mantle" and getting yourself designated as the official XDG Python reference implementation maintainer than it would be about taking over the existing pyxdg repository, per se. And, yes, I know that combining two Git repositories while maintaining attribution is kind of a messy process, though it could make sense to keep the existing pyxdg around explicitly for Python 2 compatibility and nothing else.)

By the way, feel free to use my Python port of xdg-user-dir-lookup, regardless!

FWIW, this may also help fix https://github.com/srstevenson/xdg/issues/75.

[ChanceNCounter]

One reason to choose this lib over the more "featureful" lib is that I don't need those features, but I do need to avoid the LGPL, the applicability of which to interpreted languages has never been tested in court.

The other lib is LGPL. If this lib goes away or tries to merge it, I'm screwed enough to fork.

[elsiehupp]

That is an interesting point I had not noticed! Regardless it would be nice if someone were take over responsibility for pyxdg, even if it remains separate from this library.

[srstevenson]

Thanks for opening this @elsiehupp. I'm not looking to take on maintainership of other packages at this time, however, I've commented on #75 to try to renew efforts to find a solution to the namespace collision that doesn't break existing code for either xdg or pyxdg users.