You are not logged in.
The title already describes the main issue.
Some nautilus extensions depend on python-nautilus and some on python2-nautilus.
Inspecting the two packages reveals the problem. Both packages provide the same files (in terms of file names/paths).
Isn't there any way around this? Does that mean I can either install python2 extensions or python3 extensions but not both at the same time? That doesn't sound like a logical limitation to me. Were they meant to be mutually exclusive by gnome?
If there is no solution to this problem consider the following:
I've looked into it and it seems that at least some of the extension can be run by python 2 and 3 (e.g. nautilus-terminal).
So why not have the packages python2-nautilus and python3-nautilus. Both may conflict each other and both provide python-nautilus. So extensions supporting both python 2 and 3 could depend on python-nautilus. That way at least some conflicts would be resolved.
Is this worth a bug report on bugs.archlinux.org ?
Also is there anything I could do to work around this? (i.e installing python3 and python2 extensions for nautilus at the same time?)
Thanks in advance.
Last edited by scindix (2018-12-02 18:22:01)
Offline
Does that mean I can either install python2 extensions or python3 extensions but not both at the same time? That doesn't sound like a logical limitation to me. Were they meant to be mutually exclusive by gnome?
Yes, this is intended.
I've looked into it and it seems that at least some of the extension can be run by python 2 and 3 (e.g. nautilus-terminal).
So why not have the packages python2-nautilus and python3-nautilus. Both may conflict each other and both provide python-nautilus. So extensions supporting both python 2 and 3 could depend on python-nautilus. That way at least some conflicts would be resolved.
Extensions won't tend to be dual python in the general sense, so what's the utility? Actually, what python2 extensions do you need at all?
I solve this problem in nemo, due to only providing a python3 version at all.
Managing AUR repos The Right Way -- aurpublish (now a standalone tool)
Offline
Extensions won't tend to be dual python in the general sense, so what's the utility?
No, not in general. But some are. And this would give the package maintainer the possibility to reduce conflicts. E.g. you could install nautilus-terminal and nautilus-admin at the same time.
Actually, what python2 extensions do you need at all?
There is nothing life threatening. But I find both nautilus-image-tools and nautilus-send-to-bluetooth pretty neat.
Yes, this is intended.
Really though? Because while searching for a workaround I tried to override the dependencies.
I did the following (I used pikaur for aur packages):
# pacman -S python2-nautilus
$ pikaur -S some-python2-nautilus-extensions
# pacman -Sdd python-nautilus
$ pikaur -S some-python3-nautilus-extensions
And both the python2 and python3 extensions are working perfectly. Even though the binary libnautilus-python.so differs in both packages it seems to actually do the same thing. Maybe the binary in python-nautilus supports both python versions?
Now although the above hack works it is not a real solution as -Sdd comes with a potential risk. However it proves that python2 and python3 extensions are not actually mutually exclusive.
This smells like a bug in the Arch Repositories to me.
Offline
Extensions won't tend to be dual python in the general sense, so what's the utility?
No, not in general. But some are. And this would give the package maintainer the possibility to reduce conflicts. E.g. you could install nautilus-terminal and nautilus-admin at the same time.
Actually, what python2 extensions do you need at all?
There is nothing life threatening. But I find both nautilus-image-tools and nautilus-send-to-bluetooth pretty neat.
AUR packages are unsupported. In this case, please tell the fool who packaged "nautilus-send-to-bluetooth" (and who is also the upstream developer) that it's completely stupid to depend on Python 3 and also depend on python2-nautilus, especially given that the extension itself uses "python3" in the shebang.
I suggest you look into seeing whether nautilus-image-tools is likewise available for python3, and if not, ask the developers of this 3-year-old code to update.
Yes, this is intended.
Really though? Because while searching for a workaround I tried to override the dependencies.
I did the following (I used pikaur for aur packages):# pacman -S python2-nautilus $ pikaur -S some-python2-nautilus-extensions # pacman -Sdd python-nautilus $ pikaur -S some-python3-nautilus-extensions
And both the python2 and python3 extensions are working perfectly. Even though the binary libnautilus-python.so differs in both packages it seems to actually do the same thing. Maybe the binary in python-nautilus supports both python versions?
Now although the above hack works it is not a real solution as -Sdd comes with a potential risk. However it proves that python2 and python3 extensions are not actually mutually exclusive.
This tells me that the extensions you tried, were compatible with both python2 and python3 (and must therefore depend on python3 exclusively).
It does NOT mean that libnautilus-python.so itself is compatible with both the python2 and python3 embedded interpreters. I promise you that doesn't and won't work. It's super easy to check, too, just use readelf to see which libraries it is linked to.
$ pkg-list-linked-libraries python-nautilus libpython
==> checking linked libraries for python-nautilus-1.2.2-2-x86_64.pkg.tar.xz ...
/usr/lib/nautilus/extensions-3.0/libnautilus-python.so
NEEDED libpython3.7m.so.1.0
$ pkg-list-linked-libraries python2-nautilus libpython
==> checking linked libraries for python2-nautilus-1.2.2-2-x86_64.pkg.tar.xz ...
/usr/lib/nautilus/extensions-3.0/libnautilus-python.so
NEEDED libpython2.7.so.1.0
This smells like a bug in the Arch Repositories to me.
This smells like a bug in your understanding of how shared libraries work, and of how polyglot python works, to me.
Which is ordinarily fine, not everyone is an expert at everything, but it's a bit less fine and veering towards sad instead, when people go around confidently asserting that the inability to coinstall both is somehow a bug in the Arch Repositories.
You'd be on mildly firmer ground if you stuck with suggesting we use a complex system of virtual packages in ways we don't (by distribution policy) normally do, to ensure people can automagically use old things in the name of compatibility. This is a technically possible thing to do, even if we don't often actually do so.
Last edited by eschwartz (2018-12-02 18:22:54)
Managing AUR repos The Right Way -- aurpublish (now a standalone tool)
Offline
Okay. Thanks for your explanation then.
No need to get angry though...
I didn't mean to offend anyone.
Last edited by scindix (2018-12-02 18:23:25)
Offline
Eh, I'm not really angry. I do tend to call a spade a spade, though, and it's pretty stupid for the package maintainer to list python2 for nautilus-send-to-bluetooth.
Also I truly do find myself saddened when I see people jumping to conclusions about e.g. the ability to dynload both python2 and python3 in libnautilus-python as a solution, rather than focusing on the -- to me -- clear logic of investigating the extension code itself as dual-compatible. I'm not currently at the stage of feeling wrathful thoughts. I just think it would be cool if people didn't expend fruitless energy on assuming the conclusion.
...
All this aside, I'm unsure why nautilus-terminal specifies a dependency on python2-nautilus, when there seems to be python3 try/except clauses in it... it's entirely possible this should depend on the Python 3 version too.
Managing AUR repos The Right Way -- aurpublish (now a standalone tool)
Offline