Arch Linux User Repository

I do like it, so... :D

I've recently kind-of been blamed - baselessly, without any evidence presented - by Arch's Morten Linderud of using copy-paste and unfounded reasoning. Since then, maybe I'm overdoing a bit the 'soundness' and the referential foundation of my reasoning. ':-)

I've sort of wrote this earlier partially, because I was facing this confusion myself and submitted some suggestions already to other maintainers. :)

Yeah, it seems the kupfer project was also not the most precise when declaring their xdg (pyxdg) dependency based on the Python site-packages directory name, not based on the PyPI distro name / project name.

OK, updated. So the official kupfer package got this wrong too then.

Woa man, you had me with this :D I'll update the package soon, thanks for your help!

Yes, what you might be "missing" is some "historical context". :)

TLDR; Arch/kupfer in actuality also depends on repo's python-pyxdg, not on AUR's python-xdg. And Arch's python-pyxdg should not provide python-xdg, because there exist two mutually incompatible modules on PyPI - pyxdg (official, by freedesktop.org) and xdg (unofficial, by unfriendly independent dev, conflicting with the official one).

Details:

Arch originally named PyPI's pyxdg package, freedesktop.org's official XDG support library, as pyxdg until 2012. (It was a Python 2 package.)

Then after mid-2012, they have created split packages (for Python 2 and 3), and renamed them to python2-xdg and python-xdg.

Then, in Aug 2020, Arch maintainers decided to rename the python-xdg and python2-xdg packages to python-pyxdg and python2-pyxdg.

The freedesktop.org XDG library's PyPI distribution name has always been pyxdg, right from the beginning in 2011. But it has always provided the module in a directory named 'xdg' - maybe that's where the confusion was for repo packagers.

Meanwile, in 2016, someone with the GitHub name @srstevenson decided to trump on everyone else and disregard the problems they will create, and reimplemented a tiny subset of XDG support in a completely different way than how freedesktop.org had done, and took the xdg name for themselves on PyPI. They also put their minimal and incompatible module in a directory named 'xdg'.

In 2019, that independent developer refused to address the issue raised on their GitHub - suggesting that it is freedesktop.org's project, existing since 2011, that should bend and change their module directory name.

In 2021, that same developer has shut down even the possibility of discussing this further, on the pretext that one person was rude.

Arch repo's python-pyxdg only provides python-xdg for historical reasons - because their former naming of the same Python module was python-xdg, starting from 2012 and until Aug 2020. They didn't want to change the dependencies of every Python package that was set to depend on that name. (Also, before 2016, this confusion didn't exist, as there was no rogue 'xdg' package on PyPI yet, only the official 'pyxdg'.)

In Nov 2020, a user uploaded python-xdg to AUR, based on @srstevenson's unofficial xdg's v5.0.1. Because there were like three packages on AUR out of 110+ that actually depended on that unfriendly "overwrite" module and not the official one.

Out of those three AUR packages, one (mimeo) has already implemented a changeover to use the official freedesktop.org pyxdg package; the other two (goobook and goobook-git) are in the process of doing so (merge request close to acceptance).

As for Kupfer's waf setup script, it only checks for the existence of the 'xdg' directory in Python's site-packages. If it finds that dir, the build proceeds. Though it is worth mentioning that with the official pyxdg, the waf installer outputs the actual version of pyxdg - currently 0.28 -, whereas with the unofficial module, it only outputs that the directory is 'found'.

The Kupfer app itself needs modules like xdg.DesktopEntry, and such are only provided by the official pyxdg, not by @srstevenson's version.

The latter, unofficial module has never been carried by Arch repos. But as we are in AURland, and we do have that one here, maintainers of dependent packages need to be more careful in how they define this confusing dependency in their packages. :)

So, this is the story, "briefly". :D

Well, it provides python-xdg, so that should not be a problem then or am I missing something.

The only way I see is to declare it depends on python-pyxdg, which is the official freedesktop.org library, and actually provides the 'xdg' Python module directory, with all the submodules / classes required by kupfer.

Hmm, what do you suggest as a solution? Is it any different with the kupfer package?

Though after the successful build, the application itself is defunct if I have python-xdg installed instead of python-pyxdg:

$ kupfer

Kupfer: A free software (GPLv3+) launcher
  Copyright © 2007–2017 Ulrik Sverdrup with others
  https://kupferlauncher.github.io/

Traceback (most recent call last):
  File "/usr/share/kupfer/kupfer.py", line 23, in <module>
    main.main()
  File "/usr/share/kupfer/kupfer/main.py", line 177, in main
    gtkmain(browser_start, quiet)
  File "/usr/share/kupfer/kupfer/main.py", line 146, in gtkmain
    return run_function(*args, **kwargs)
  File "/usr/share/kupfer/kupfer/main.py", line 154, in browser_start
    from kupfer.ui import browser
  File "/usr/share/kupfer/kupfer/ui/browser.py", line 23, in <module>
    from kupfer import kupferui
  File "/usr/share/kupfer/kupfer/kupferui.py", line 6, in <module>
    from kupfer import utils, version
  File "/usr/share/kupfer/kupfer/utils.py", line 15, in <module>
    from kupfer import desktop_launch
  File "/usr/share/kupfer/kupfer/desktop_launch.py", line 5, in <module>
    import xdg.DesktopEntry
ModuleNotFoundError: No module named 'xdg.DesktopEntry'