You are not logged in.
[Solved(Workaround)] For the time being, I can have python-pyxdg (the Community package installed via pacman), and python-xdg (AUR package) installed and usable at the same time by installing any Python packages which depend on python-xdg in a Python venv (Virtual Environment). See my reply below for details on how I was able to work around the problem. Thanks to python-xdg maintainer jaantoots for the idea.
Xyne created the wonderful mimeo: open files by mimetype or file name utility, which until recently I had been using to open files and URLs from my favorite terminal emulator (Alacritty).
With my upgrade to Python 3.9, a crucial dependency of mimeo (python-xdg) was changed. On the AUR page for mimeo, it shows that it depends on python-xdg (python-pyxdg). python-xdg now conflicts with python-pyxdg, and anything depending on python-pyxdg is broken until I reinstall it. If I reinstall python-pyxdg anything depending on the new python-xdg is broken. Because the two packages are officially conflicting, I can't get everything to work.
I don't know where to actually begin asking for help. I've posted on the respective AUR comment pages, but thus far I haven't received a response from any of the maintainers. Upstream links don't appear to have bug or issue trackers I can post to, and I don't know if the Free Desktop folks are the right ones to ask for this.
Last edited by ectospasm (2021-01-07 03:04:01)
Offline
Have you updated mimeo recently? I did a clean install of it and it pulled python-pyxdg as a dependency instead of python-xdg and seems to be working.
Offline
Have you updated mimeo recently? I did a clean install of it and it pulled python-pyxdg as a dependency instead of python-xdg and seems to be working.
Ah, yes, that is a solution. However, installing python-pyxdg breaks anything that depends on python-xdg. I can install python-pyxdg but things like goobook break. The maintainer for python-xdg also maintains goobook, and he stated the following (in the AUR comments on python-xdg):
Both packages want to live in `/usr/lib/python3.9/site-packages/xdg/`,
so I don't think there is much that can be done by package
maintainers.Both packages exist on PyPI and pip happily just overwrites the files
if you try to install both. I don't really see a way for both of them
to coexist in the same environment.I guess you can try complaining to respective upstream projects. But
you are probably better off by simply avoiding the system packages for
either (if it is feasible to run what you want in virtualenvs,
containers, etc.).
So I will have to wait until python-pyxdg and python-xdg converge, or I will have to see if I can get the stuff that depends on python-xdg to work in a virtualenv.
Offline
You could try symlinking one as the other. Not sure how much breakage could occur though.
Offline
You could try symlinking one as the other. Not sure how much breakage could occur though.
I doubt that would work, as python-pyxdg and python-xdg occupy the same directory at the system level. What would I make a symlink of? The problem is when a package imports the xdg module or submodules, there is no other way to distinguish which xdg the author intended. If the Python script requires the other package, importing the installed package will fail every time. I can't imagine that a simple symlink would solve that in any meaningful way.
It looks like Python venv is the way to go, that way I can install goobook (and anything else that depends on the new/AUR python-xdg) without interfering with the python-pyxdg installed at the Arch/pacman level. Once I get the python-xdg venv running, I can use pip to install anything that depends on python-xdg, and use pacman + AUR PKGBUILDs to install anything that still relies on python-pyxdg. I'll just have to keep in mind that anything that depends on python-xdg (in the venv) will have to be installed using pip until the situation with python-pyxdg and python-xdg is converged (or otherwise resolved).
Once I have the venv installed, I can add the scripts to /usr/local/bin, and ensure that appears first in the PATH. The venv does not need to be activated to use the executables contained in the venv, but they will use the venv environment for execution (including any Python modules and dependencies). Thanks to jaantoots for giving me the idea, I'm trying to implement it now.
Offline
I was able to have both python-pyxdg and python-xdg installed at the same time, by using a venv for python-xdg. Here's how I did it:
Get a root shell:
$ sudo -i
Create the venv directory:
# mkdir -p /usr/local/venv/python-xdg
Create the venv:
# python -m venv /usr/local/venv/python-xdg
Activate the venv:
# source /usr/local/venv/python-xdg/bin/activate
Upgrade pip in the venv:
# pip install --upgrade pip
Install the packages that depend on python-xdg in the venv (in my case, only goobook requires python-xdg):
# pip install goobook
Deactivate the venv:
# deactivate
Further executions of pip will use the system Python environment, rather than the venv. For this reason using pip outside of the venv should be discouraged (use pacman or AUR PKGBUILDs to install most programs, unless it pulls in the python-xdg package). pacman should warn that python-xdg conflicts with python-pyxdg, and that should be enough to jog your memory about this process. If it doesn't jog your memory, you'll have broken Python packages until you remember this procedure.
Create a symlink to the venv executables you want to use:
# ln -s /usr/local/venv/python-xdg/bin/goobook /usr/local/bin
This will ensure the desired programs will be launched using the venv, even though the venv is not activated.
Exit the root shell:
# exit # or Ctlr-D
Now both mimeo and goobook work, even though they depend on vastly different Python xdg modules!
Last edited by ectospasm (2021-01-07 03:26:33)
Offline
MOD NOTE: Not a Community Contribution; moving to "AUR Issues, Discussion & PKGBUILD Requests"
Are you familiar with our Forum Rules, and How To Ask Questions The Smart Way?
BlueHackers // fscanary // resticctl
Offline
Thanks for posting the work-around, ectospasm!
[...] Upstream links don't appear to have bug or issue trackers I can post to, and I don't know if the Free Desktop folks are the right ones to ask for this.
For anyone who might be interested in this, there's an issue on the GitHub repository of python-xdg where the module name conflict has been discussed.
Offline