Cause of this issue: nautilus_python_init_python (nautilus-python.c:156/157) constructs an incorrect path for loading the python 3.7 library. Shouldn't it load python 3.7 through pkgconfig?

Thanks for the report. Support for python3-nautilus was introduced recently, see bug #1607043.

> The file /usr/lib64/libpython3.7.so.1.0 does not exist. Instead, the python3-libs-3.7.0-9.fc29.x86_64 package provides a slightly differently named file, /usr/lib64/libpython3.7m.so.1.0

There are two binaries: %{_bindir}/python3.7 and %{_bindir}/python3.7m, I don't know the reason for python3.7m, maybe there's a symlink missing for the library.

Provides of python3-libs-3.7.0-9.fc29.x86_64.rpm (excerpt):
libpython3.7m.so.1.0()(64bit)
libpython3.so()(64bit)

Why does nautilus look for any python3 while there's (only?) python2-nautilus installed? Please try: rpm -q python3-nautilus

What happens if you try to remove python2-nautilus?

No idea what's meant with 'thunar'. Maybe nautilus tries to find any thunar plugins?

> There are two binaries: %{_bindir}/python3.7 and %{_bindir}/python3.7m, I don't know the reason for python3.7m, maybe there's a symlink missing for the library.

Those are the same files, i.e. they are two hardlinks to the same data.

> Provides of python3-libs-3.7.0-9.fc29.x86_64.rpm (excerpt):
> libpython3.7m.so.1.0()(64bit)
> libpython3.so()(64bit)

Looks fine to me. These files are also installed. It looks like it would be wiser to load libpython3.so instead which may figure out which exact python library to load.

> Why does nautilus look for any python3 while there's (only?) python2-nautilus installed? Please try: rpm -q python3-nautilus

I don't know.

    $ rpm -q python3-nautilus
    python3-nautilus-1.2.1-3.fc29.x86_64

> What happens if you try to remove python2-nautilus?

It will also remove kde-connect-nautilus (which I would like to avoid). Starting nautilus after removing python2-nautilus does make the message go away.

> No idea what's meant with 'thunar'. Maybe nautilus tries to find any thunar plugins?

Found it in the source code of nautilus_python_init_python() (nautilus-python.c:170/172).

Ok, I've tried a different approach: Removing/installing the python{2,3}-nautilus packages separately. The issue is present only if python2-nautilus is installed but not if python3-nautilus is.

Matrix:
* both installed: bug happens
* only python2-nautilus installed: bug happens
* only python3-nautilus installed: bug does not happen

This lead me to look closer into the `nautilus_python_init_python()` function. It constructs the path to load the library from by concatenating it from compile-time variables (line 157):

    libpython = g_module_open (PY_LIB_LOC "/lib" PY_LIB_NAME "." G_MODULE_SUFFIX ".1.0", 0);

the interesting (incorrect) one is PY_LIB_NAME which is being passed to the compiler from automake makefiles (src/Makefile.am:11, [1]). It is being set in m4/python.m4:155 after being generated in line 138/139 [2].

    py_include_path=`$PYTHON -c "from distutils.sysconfig import get_python_inc; print(get_python_inc())"`

This is where the build script determines the python version to use for nautilus-python.

Speculation: I *think* the python2-nautilus binary is just being built with $PYTHON set to python3 instead of python2.


[1] https://gitlab.gnome.org/GNOME/nautilus-python/blob/master/src/Makefile.am#L11
[2] https://gitlab.gnome.org/GNOME/nautilus-python/blob/master/m4/python.m4#L139

(In reply to Christian Stadelmann from comment #3)
> > What happens if you try to remove python2-nautilus?
> 
> It will also remove kde-connect-nautilus (which I would like to avoid).
> Starting nautilus after removing python2-nautilus does make the message go
> away.

I know this is a bit off the scope of this bug report, but I'd like to clarify it too:
python2-nautilus has "Provides: nautilus-python" but python3-nautilus has not. Does that mean that kde-connect-nautilus should depend on python3-nautilus directly if it does support being run with python 3?

(In reply to Christian Stadelmann from comment #5)
…
> I know this is a bit off the scope of this bug report, but I'd like to
> clarify it too:
> python2-nautilus has "Provides: nautilus-python" but python3-nautilus has
> not. Does that mean that kde-connect-nautilus should depend on
> python3-nautilus directly if it does support being run with python 3?

Yes. We renamed the subpackages to be able to differ the python versions. It's in our guidelines to do so. The Provides is there for backwards compatibility. As I don't know anything about kde-connect-nautilus and its support for python3, you should open another bug against this component if you think it should work with python3 instead.

I can take a look into the other issue later, comment #3 and comment #4. Thanks for digging into it.

(In reply to Raphael Groner from comment #6)
> (In reply to Christian Stadelmann from comment #5)
> …
> > I know this is a bit off the scope of this bug report, but I'd like to
> > clarify it too:
> > python2-nautilus has "Provides: nautilus-python" but python3-nautilus has
> > not. Does that mean that kde-connect-nautilus should depend on
> > python3-nautilus directly if it does support being run with python 3?
> 
> Yes. We renamed the subpackages to be able to differ the python versions.
> It's in our guidelines to do so. The Provides is there for backwards
> compatibility. As I don't know anything about kde-connect-nautilus and its
> support for python3, you should open another bug against this component if
> you think it should work with python3 instead.

Ok, done in bug #1636941.

Hi there.

I have similar messages with folder-color.py (https://launchpad.net/folder-color) Nautilus extension, which should run on Python2. It worked fine in Fedora 28.

Here they are:
-------------------------------------
nautilus   

(nautilus:9172): Nautilus-Python-WARNING **: 14:17:06.114: g_module_open libpython failed: /usr/lib64/libpython3.7.so.1.0: cannot open shared object file: No such file or directory
ImportError: could not import gobject (error was: ImportError('/usr/lib64/python3.7/site-packages/gi/_gi.cpython-37m-x86_64-linux-gnu.so: undefined symbol: PyExc_NotImplementedError'))

(nautilus:9172): Nautilus-Python-WARNING **: 14:17:06.611: pygobject initialization failed

(nautilus:9172): Nautilus-Python-WARNING **: 14:17:06.612: nautilus_python_init_python failed
Traceback (most recent call last):
  File "/usr/share/nautilus-python/extensions/folder-color.py", line 19, in <module>
    import os, urllib, gettext, glob, webbrowser, operator, shutil, ConfigParser, subprocess
ModuleNotFoundError: No module named 'ConfigParser'
-------------------------------------

In Python3, ConfigParser is renamed to configparser. But I have Python2 and python2-gobject installed.

$ rpm -qa | grep gobject
python2-gobject-3.30.1-1.fc29.x86_64
python3-gobject-base-3.30.1-1.fc29.x86_64
gobject-introspection-1.58.0-2.fc29.x86_64
pygobject2-2.28.7-4.fc29.x86_64
cairo-gobject-devel-1.15.14-1.fc29.x86_64
python2-gobject-base-3.30.1-1.fc29.x86_64
cairo-gobject-1.15.14-1.fc29.x86_64
python3-gobject-3.30.1-1.fc29.x86_64
libvirt-gobject-1.0.0-7.fc29.x86_64

$ rpm -qa | grep nautilus
evince-nautilus-3.30.1-2.fc29.x86_64
file-roller-nautilus-3.30.1-1.fc29.x86_64
nautilus-3.30.1-1.fc29.x86_64
nautilus-extensions-3.30.1-1.fc29.x86_64
python2-nautilus-1.2.1-3.fc29.x86_64
totem-nautilus-3.26.2-1.fc29.x86_64
nautilus-sendto-3.8.6-3.fc29.x86_64

python2-nautilus is broken, it shouldn't require python3!


$ sudo dnf repoquery --requires python2-nautilus |grep python
Last metadata expiration check: 0:33:00 ago on Thu 11 Oct 2018 11:13:38 BST.
libpython3.7m.so.1.0()(64bit)

(In reply to leigh scott from comment #9)
> python2-nautilus is broken, it shouldn't require python3!

Indeed, python2-nautilus ships the python3 build with the same name:
%{_libdir}/nautilus/extensions-%{NAUTILUS_MAYOR_VER}/lib%{name}.so

That happens because the build with python2 should better happen after python3 and in prior the result from python3 needs to get renamed and installed with another name.

Or can we drop the subpackage for python2 entirely to comply with announced EOL of python2? No idea what dependencies there are to think about.

*** Bug 1644404 has been marked as a duplicate of this bug. ***

nautilus-python-1.2.1-4.fc29 has been submitted as an update to Fedora 29. https://bodhi.fedoraproject.org/updates/FEDORA-2018-068061b361

nautilus-python-1.2.1-4.fc29 has been pushed to the Fedora 29 testing repository. If problems still persist, please make note of it in this bug report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2018-068061b361

I installed python2-nautilus-1.2.1-4.fc29.x86_64 from the updates-testing repo, and now it won't even start.
The console output when I launch nautilus from the command line is:

Initializing Nextcloud-client-nautilus extension
Socket File: /run/user/1000/Nextcloud/socket
Setting connected to True.
Socket watch id: 15
sys:1: Warning: Two different plugins tried to register 'SyncStateExtension+NautilusPython'.
sys:1: Warning: g_type_add_interface_dynamic: assertion 'G_TYPE_IS_INSTANTIATABLE (instance_type)' failed
sys:1: Warning: Two different plugins tried to register 'MenuExtension+NautilusPython'.
sys:1: Warning: Two different plugins tried to register 'HgExtension+NautilusPython'.
fish: 'nautilus' terminated by signal SIGSEGV (Address boundary error)

sys:1: Warning: Two different plugins tried to register 'OpenTilixExtension+NautilusPython'.
sys:1: Warning: g_type_add_interface_dynamic: assertion 'G_TYPE_IS_INSTANTIATABLE (instance_type)' failed
sys:1: Warning: Two different plugins tried to register 'OpenTilixShortcutProvider+NautilusPython'.
[1]    27041 segmentation fault (core dumped)  nautilus

please execute 

sudo dnf remove tilix-nautilus

and segmentation fault gone and open normally

but still missing open terminal in tilix

explanation 

maybe nautilus-extension include now tilix-nautilus

Regards.,

(In reply to Franco Bugnano from comment #14)
> I installed python2-nautilus-1.2.1-4.fc29.x86_64 from the updates-testing
> repo, and now it won't even start.
> The console output when I launch nautilus from the command line is:
> 
> Initializing Nextcloud-client-nautilus extension
> Socket File: /run/user/1000/Nextcloud/socket
> Setting connected to True.
> Socket watch id: 15
> sys:1: Warning: Two different plugins tried to register
> 'SyncStateExtension+NautilusPython'.
> sys:1: Warning: g_type_add_interface_dynamic: assertion
> 'G_TYPE_IS_INSTANTIATABLE (instance_type)' failed
> sys:1: Warning: Two different plugins tried to register
> 'MenuExtension+NautilusPython'.
> sys:1: Warning: Two different plugins tried to register
> 'HgExtension+NautilusPython'.
> fish: 'nautilus' terminated by signal SIGSEGV (Address boundary error)

please remove :

sudo dnf remove nextcloud-client-nautilus

explanation 

sys:1: Warning: Two different plugins tried to register 'SyncStateExtension+NautilusPython'.

maybe nautilus-extension include now nextcloud-client-nautilus

regards.,

Well, please consider to open another bugs against those extensions. I packaged what upstream provides. Maybe those extensions need a rebuild against the new version of nautilus-python.

(In reply to Héctor Louzao from comment #17)
> (In reply to Franco Bugnano from comment #14)
> > I installed python2-nautilus-1.2.1-4.fc29.x86_64 from the updates-testing
> > repo, and now it won't even start.
> > The console output when I launch nautilus from the command line is:
> > 
> > Initializing Nextcloud-client-nautilus extension
> > Socket File: /run/user/1000/Nextcloud/socket
> > Setting connected to True.
> > Socket watch id: 15
> > sys:1: Warning: Two different plugins tried to register
> > 'SyncStateExtension+NautilusPython'.
> > sys:1: Warning: g_type_add_interface_dynamic: assertion
> > 'G_TYPE_IS_INSTANTIATABLE (instance_type)' failed
> > sys:1: Warning: Two different plugins tried to register
> > 'MenuExtension+NautilusPython'.
> > sys:1: Warning: Two different plugins tried to register
> > 'HgExtension+NautilusPython'.
> > fish: 'nautilus' terminated by signal SIGSEGV (Address boundary error)
> 
> please remove :
> 
> sudo dnf remove nextcloud-client-nautilus
> 
> explanation 
> 
> sys:1: Warning: Two different plugins tried to register
> 'SyncStateExtension+NautilusPython'.
> 
> maybe nautilus-extension include now nextcloud-client-nautilus
> 
> regards.,

I don't understand what you mean by maybe nautilus-extension include now nextcloud-client-nautilus.

I don't believe that the python2-nautilus package includes ALL the possible extensions. Moreover, I removed the nextcloud-client-nautilus and tortoisehg-nautilus packages, but when browsing to a Nexcloud synchronized folder, or to a Mercurial repo, no overlays appear, and no new menu items appear, so those packages are still required.

(In reply to Raphael Groner from comment #18)
> Well, please consider to open another bugs against those extensions. I
> packaged what upstream provides. Maybe those extensions need a rebuild
> against the new version of nautilus-python.

Before opening a bug against those extensions, I just want to know whether it makes any sense for rpm packages that contain only Python files to be rebuilt. I mean, there is no compilation process whatsoever, only copying a file to the right directory, and that's it. Or am I missing something?

I have GSConnect installed and when I upgraded to python2-nautilus-1.2.1-4, nautilus broke:

$ nautilus
sys:1: Warning: Two different plugins tried to register 'GSConnectShareExtension+NautilusPython'.
sys:1: Warning: g_type_add_interface_dynamic: assertion 'G_TYPE_IS_INSTANTIATABLE (instance_type)' failed

This issue is not present in python2-nautilus-1.2.1-3.

https://github.com/andyholmes/gnome-shell-extension-gsconnect/issues/293

(In reply to Raphael Groner from comment #18)
> Well, please consider to open another bugs against those extensions. I
> packaged what upstream provides. Maybe those extensions need a rebuild
> against the new version of nautilus-python.

What good would rebuilding a python package do?, unless you think the byte recompile will help?
Are you being completely clueless to the real issue on purpose?


YOU CAN ONLY ONE NAUTILUS_PYTHON* PACKAGE, NOT BOTH!!!!


sys:1: Warning: Two different plugins tried to register 'OpenTilixShortcutProvider+NautilusPython'.


This error is clear as day, but you decide to blame the other extensions.
Let me translate it for you.

both nautilus-python* packages tried to register OpenTilixShortcutProvider, is that clear enough?

With all extensions removed but with python2-nautilus-1.2.1-4 installed, running nautilus in terminal returns:

$ nautilus
Traceback (most recent call last):
  File "/usr/lib64/python2.7/site-packages/gi/importer.py", line 145, in load_module
    importlib.import_module('gi.repository.' + dep.split("-")[0])
  File "/usr/lib64/python2.7/importlib/__init__.py", line 37, in import_module
    __import__(name)
  File "/usr/lib64/python2.7/site-packages/gi/importer.py", line 145, in load_module
    importlib.import_module('gi.repository.' + dep.split("-")[0])
  File "/usr/lib64/python2.7/importlib/__init__.py", line 37, in import_module
    __import__(name)
  File "/usr/lib64/python2.7/site-packages/gi/importer.py", line 145, in load_module
    importlib.import_module('gi.repository.' + dep.split("-")[0])
  File "/usr/lib64/python2.7/importlib/__init__.py", line 37, in import_module
    __import__(name)
  File "/usr/lib64/python2.7/site-packages/gi/importer.py", line 145, in load_module
    importlib.import_module('gi.repository.' + dep.split("-")[0])
  File "/usr/lib64/python2.7/importlib/__init__.py", line 37, in import_module
    __import__(name)
  File "/usr/lib64/python2.7/site-packages/gi/importer.py", line 145, in load_module
    importlib.import_module('gi.repository.' + dep.split("-")[0])
  File "/usr/lib64/python2.7/importlib/__init__.py", line 37, in import_module
    __import__(name)
  File "/usr/lib64/python2.7/site-packages/gi/importer.py", line 146, in load_module
    dynamic_module = load_overrides(introspection_module)
  File "/usr/lib64/python2.7/site-packages/gi/overrides/__init__.py", line 125, in load_overrides
    override_mod = importlib.import_module(override_package_name)
  File "/usr/lib64/python2.7/importlib/__init__.py", line 37, in import_module
    __import__(name)
  File "/usr/lib64/python2.7/site-packages/gi/overrides/GLib.py", line 156, in <module>
    class Variant(GLib.Variant):
  File "/usr/lib64/python2.7/site-packages/gi/types.py", line 340, in __init__
    super(StructMeta, cls).__init__(name, bases, dict_)
TypeError: Error when calling the metaclass bases
    'NoneType' object is not callable

(nautilus:13605): Nautilus-Python-WARNING **: 15:40:20.561: nautilus_python_init_python failed

While with python3-nautilus-1.2.1-4:

$ nautilus

(nautilus:13742): Nautilus-Python-WARNING **: 15:47:17.301: g_module_open libpython failed: /usr/lib64/libpython3.7.so.1.0: cannot open shared object file: No such file or directory
ImportError: could not import gobject (error was: ImportError('/usr/lib64/python3.7/site-packages/gi/_gi.cpython-37m-x86_64-linux-gnu.so: undefined symbol: PyExc_NotImplementedError'))

(nautilus:13742): Nautilus-Python-WARNING **: 15:47:17.358: pygobject initialization failed

(nautilus:13742): Nautilus-Python-WARNING **: 15:47:17.358: nautilus_python_init_python failed

(In reply to Basil Eric Rabi from comment #23)
> While with python3-nautilus-1.2.1-4:
> 
> $ nautilus
> 
> (nautilus:13742): Nautilus-Python-WARNING **: 15:47:17.301: g_module_open
> libpython failed: /usr/lib64/libpython3.7.so.1.0: cannot open shared object
> file: No such file or directory
> ImportError: could not import gobject (error was:
> ImportError('/usr/lib64/python3.7/site-packages/gi/_gi.cpython-37m-x86_64-
> linux-gnu.so: undefined symbol: PyExc_NotImplementedError'))
> 
> (nautilus:13742): Nautilus-Python-WARNING **: 15:47:17.358: pygobject
> initialization failed
> 
> (nautilus:13742): Nautilus-Python-WARNING **: 15:47:17.358:
> nautilus_python_init_python failed

python3-gobject-base should be a Requires: for python3-nautilus package.
It isn't currently.

$ rpm -qp --requires https://kojipkgs.fedoraproject.org//packages/nautilus-python/1.2.1/4.fc29/x86_64/python3-nautilus-1.2.1-4.fc29.x86_64.rpm |grep python
libpython3.7m.so.1.0()(64bit)

(In reply to Franco Bugnano from comment #19)
> I don't believe that the python2-nautilus package includes ALL the possible
> extensions. Moreover, I removed the nextcloud-client-nautilus and
> tortoisehg-nautilus packages, but when browsing to a Nexcloud synchronized
> folder, or to a Mercurial repo, no overlays appear, and no new menu items
> appear, so those packages are still required.

You do not need to believe, you can know it:

$ rpmreaper python2-nautilus

then select the correct package and press "i" for information

/usr/lib/.build-id
/usr/lib/.build-id/77
/usr/lib/.build-id/77/da9ef0827d371b632ad381f8b95d8d0c82c624
/usr/lib64/nautilus/extensions-3.0/libnautilus-python.so
/usr/share/doc/python2-nautilus
/usr/share/doc/python2-nautilus/AUTHORS
/usr/share/doc/python2-nautilus/NEWS
/usr/share/doc/python2-nautilus/README
/usr/share/licenses/python2-nautilus
/usr/share/licenses/python2-nautilus/COPYING
/usr/share/nautilus-python/extensions

Interestingly, there is only one build (.so library) generated for both the python2 and python3 versions.

(In reply to leigh scott from comment #21)
> (In reply to Raphael Groner from comment #18)
> > Well, please consider to open another bugs against those extensions. I
> > packaged what upstream provides. Maybe those extensions need a rebuild
> > against the new version of nautilus-python.
> 
> What good would rebuilding a python package do?, unless you think the byte
> recompile will help?
> Are you being completely clueless to the real issue on purpose?
> 
> 
> YOU CAN ONLY ONE NAUTILUS_PYTHON* PACKAGE, NOT BOTH!!!!
> 
> 
> sys:1: Warning: Two different plugins tried to register
> 'OpenTilixShortcutProvider+NautilusPython'.
> 
> 
> This error is clear as day, but you decide to blame the other extensions.
> Let me translate it for you.
> 
> both nautilus-python* packages tried to register OpenTilixShortcutProvider,
> is that clear enough?

Please keep your voice down. This is not a place to attack other Fedora users. You stated your message clearly enough to be heard.

(In reply to Christian Stadelmann from comment #25)
> Interestingly, there is only one build (.so library) generated for both the
> python2 and python3 versions.

This means: The package does provide only one shared library (same SHA512 for both versions) no matter whether you install the python2 or python3 versions. This is clearly wrong. There should be two different shared libraries at two different locations, otherwise it will always break.

(In reply to Christian Stadelmann from comment #26)
> (In reply to leigh scott from comment #21)
> > (In reply to Raphael Groner from comment #18)
> > > Well, please consider to open another bugs against those extensions. I
> > > packaged what upstream provides. Maybe those extensions need a rebuild
> > > against the new version of nautilus-python.
> > 
> > What good would rebuilding a python package do?, unless you think the byte
> > recompile will help?
> > Are you being completely clueless to the real issue on purpose?
> > 
> > 
> > YOU CAN ONLY ONE NAUTILUS_PYTHON* PACKAGE, NOT BOTH!!!!
> > 
> > 
> > sys:1: Warning: Two different plugins tried to register
> > 'OpenTilixShortcutProvider+NautilusPython'.
> > 
> > 
> > This error is clear as day, but you decide to blame the other extensions.
> > Let me translate it for you.
> > 
> > both nautilus-python* packages tried to register OpenTilixShortcutProvider,
> > is that clear enough?
> 
> Please keep your voice down. This is not a place to attack other Fedora
> users. You stated your message clearly enough to be heard.

Thank you.

Let's get an overview of all the issues tracked in this bug report:

1. both the python2 and python3 subpackages ship the same shared library (which is only depending on python3). This is clearly a bug in nautilus-python, probably happening at build time. It seems like the python2 library is being generated and overwritten by the python3 library.
2. Extensions need a way to specify whether they are designed for python2 or python3. This is also enforced by the Fedora packaging guidelines which require different subpackages for python2 and python3. This should probably be done by installing them into separate folders. Currently, extensions are placed below /usr/share/nautilus-python/extensions/ which was for python2. One could place extensions for python3 below a new folder, /usr/share/nautilus-python/extensions-python3/. This issue probably needs upstream code and upstream conventions to be fixed.
3. Make sure that nautilus can load both python2-nautilus and python3-nautilus at the same time.
4. Fix dependencies on python3-nautilus (see comment #24)
5. Make sure the extensions do their thing right (build for python2 or python3, dependencies on python2-nautilus, python3-nautilus). See bug #1636941 for an example.

This solution requires different sonames for the python2 and python3 versions. This change is probably done best by upstream of both nautilus-python and the extensions. If they are not interested, you probably should rather not allow installing the python2 and python3 versions in parallel. Therefore, I suggest an alternative solution:
Support only one python version per distribution release. For stability reasons, this should be python2 on Fedora 29 and earlier and for support reasons, it should be python3 on Fedora 30 and later.
Steps needed here:
A1. build nautilus-python without python3 support on Fedora 29, reverting the change to support python3.
A2. build nautilus-python without python2 support on Fedora 30+ (current rawhide).
A3. notify all extensions that their code may break on rawhide and that they have about 5 months to fix their extensions.

Christian, thanks for your deeper interest. Do you want to become a co-maintainer? If yes, please feel free to request and let me know your FAS nick to let assign ACL to you.

Lessons learned here.

Proposed solution from my side:
. Revert back to version 1.1 [0] as before the bump with python3 subpackage.
. Introduce optionally Epoch and keep it forever till someone decides again to 
  build and use current versions of real upstream releases.
. Remove the new python3 subpackage entirely and stop future.
. Orphan this package.

Maybe libpeas [1][2] can solve the issue for upstream, this should get requested there and not from a packager like me. But hey, I don't care any further. You shouldn't attack contributors trying their best to fix a package that was already b0rken before they had any fingers on it.
For your interest, python2 is announced to go for EOL [4] in the next year, so tried at least to provide a base to port all those extensions. As it now turns out, nautilus [3] isn't aware of python3 and does not support two different back-ends with difference in the interpreter version but for the same file extension of the script files (*.py).

Assigning this bug to nautilus-extensions or nautilus maintainers. Maybe they better know about future plans of upstream to (additionally?) support python3.

[0] https://src.fedoraproject.org/rpms/nautilus-python/c/28f11a869deee8437bd8d73579eb000bdbfe0cfe?branch=master
[1] https://wiki.gnome.org/Projects/Libpeas
[2] https://src.fedoraproject.org/rpms/libpeas
[3] https://people.gnome.org/~bmsmith/build/gosnautilus-440.html
[4] https://pythonclock.org/

{This bug makes me sad and angry about the status of our community.}

(In reply to Christian Stadelmann from comment #27)
> (In reply to Christian Stadelmann from comment #25)
> > Interestingly, there is only one build (.so library) generated for both the
> > python2 and python3 versions.
> 
> This means: The package does provide only one shared library (same SHA512
> for both versions) no matter whether you install the python2 or python3
> versions. This is clearly wrong. There should be two different shared
> libraries at two different locations, otherwise it will always break.

This isn't possible (or thought of) with general and current design of the API for nautilus extensions.

(In reply to Christian Stadelmann from comment #25)
…
> Interestingly, there is only one build (.so library) generated for both the
> python2 and python3 versions.

This isn't true any more with my latest build on bodhi but it got unpushed.

(In reply to leigh scott from comment #24)
> (In reply to Basil Eric Rabi from comment #23)
…
> python3-gobject-base should be a Requires: for python3-nautilus package.
> It isn't currently.
> 
> $ rpm -qp --requires
> https://kojipkgs.fedoraproject.org//packages/nautilus-python/1.2.1/4.fc29/
> x86_64/python3-nautilus-1.2.1-4.fc29.x86_64.rpm |grep python
> libpython3.7m.so.1.0()(64bit)

Why do you care about the new python3 subpackage? All extensions should still work with python2 as legacy. Please try to remove python3 subpackage.

All I can find in upstream log about explicit tries with python3 is
. an entry that mentions generation of documentation
https://gitlab.gnome.org/GNOME/nautilus-python/commit/6339d52e764db031fb2cba035917def121254394
. an entry that mentions (initial) support for python3
https://gitlab.gnome.org/GNOME/nautilus-python/commit/12687a3c107c7141eaf46da7752e6b82d669f23b

Maybe someone can look deeper into the sources. As I'm doing packaging mostly in my spare time, there's not much interest any more to fix something here.

Does it work for you with python2-nautilus-1.2.1-3.fc29 as the latest build pushed in F29? If yes, we would be fine with just dropping the python3 subpackage.
Unfortunately, version 1.1 did lead us to FTBFS and then we introduced version 1.2.1 without any build failure. Therefore I assume it's difficult to go back to the previous version in current builds.

Raphael, are you ok with me going ahead and fixing this? There are a few things going wrong with the packaging here, and I think the root cause is that nautilus-python only supports one Python version at a time (you can't register an extension twice, once with Python 2 and once with Python 3). I think a good plan here is to build nautilus-python against Python 2 in F29 and switch to Python 3 in F30.

*** Bug 1645731 has been marked as a duplicate of this bug. ***

Kalev, please go ahead and do the unavoidable.
This package is just too hot for my fingers and obviously, I've already managed to burned them, a second time will definitely not happen.
Can you do it with a provenpackager hat or I've assigned ACL to you. Thanks a lot for your help! Isn't there any SIG to assign for all the nautilus extensions and stuff?

P.S. It seems I got admin ACL because I've built a package for epel7. Pagure is too dump to difference between the branches, good old PkgDB had this really missed feature.

(In reply to Kalev Lember from comment #36)
> Raphael, are you ok with me going ahead and fixing this? There are a few
> things going wrong with the packaging here, and I think the root cause is
> that nautilus-python only supports one Python version at a time (you can't
> register an extension twice, once with Python 2 and once with Python 3). I
> think a good plan here is to build nautilus-python against Python 2 in F29
> and switch to Python 3 in F30.

I would propose a different route to fix this problem:
If we revert the package as it was in F28, this will break again in F30.
Let's take advantage of this breakage instead, and fix the problem once and for all in the following way:

As Python2 will be retired in 2020, and nautilus-python can be built against a single Python version, let's build only the Python3 version instead, and repackage all the components that needed python2-nautilus to require python3-nautilus.

If an extension breaks after this change, it means that the upstream extension should be ported to Python3, but such porting will be necessary in any case due to the Python2 EOL nearing day by day.

(In reply to Franco Bugnano from comment #39)
> 
> I would propose a different route to fix this problem:
> If we revert the package as it was in F28, this will break again in F30.
> Let's take advantage of this breakage instead, and fix the problem once and
> for all in the following way:
> 
> As Python2 will be retired in 2020, and nautilus-python can be built against
> a single Python version, let's build only the Python3 version instead, and
> repackage all the components that needed python2-nautilus to require
> python3-nautilus.
> 
> If an extension breaks after this change, it means that the upstream
> extension should be ported to Python3, but such porting will be necessary in
> any case due to the Python2 EOL nearing day by day.

I've confirmed with Andy Holmes, the developer of GSConnect, that nautilus-gsconnect.py is fully Python 3 compatible. So, this would be the preferred solution from the GSConnect end.

Getting rid of python2-nautilus in F29 would also mean that there is only one python*-nautilus package in the repo, same as previous releases (which only offered python2-nautilus). Having _both_ python2-nautilus and python3-nautilus in F29, while a nice idea from a migration perspective, is clearly the core of the problem here. 

So, I agree, let's rip off the bandage now and just swap python3-nautilus in for python2-nautilus (moving the "Provides: nautilus-python" to the python3-nautilus package in the process). Then it's done and we never have to think about this again. (Until Python 4.) ;-)

I also wanted to raise a sort of side issue regarding the names for these subpackages, and whether that may have accidentally contributed to creating this bug.

It's long been the norm in Fedora to supply both `python2-` and `python3-` packages for any given Python module (when it supports both generations). Those packages are assumed and expected to be safely installable side-by-side if needed. After all, only one will ever be used by any particular piece of code, and their contents are totally segregated: /usr/lib/python2.7/ vs. /usr/lib/python3.7/.

But python2-nautilus and python3-nautilus _don't_ contain a Python module that's been packaged for two different Python generations. In fact they don't provide any Python code at all. Neither package contains ANYTHING that extends or enhances the capabilities of the `python2` or `python3` interpreters:

$ sudo dnf repoquery -l python3-nautilus| egrep -v '(doc|license|build)'
/usr/lib64/nautilus/extensions-3.0/libnautilus-python.so
/usr/share/nautilus-python/extensions

$ sudo dnf repoquery -l python2-nautilus|egrep -v '(doc|license|build)'
/usr/lib64/nautilus/extensions-3.0/libnautilus-python.so
/usr/share/nautilus-python/extensions

What these packages DO contain is a Nautilus extension called `nautilus-python`. Whether that extension is built with Python 2 or Python 3 is a packaging decision. But since there's only one nautilus, trying to have two completely different versions of its Python extension installed at the same time seems like an obviously bad idea. If the package were named better, its name would help to convey that idea.

Naming these packages `python2-nautilus` and `python3-nautilus` is simply not accurate. In fact it's dangerously misleading, and can create false impressions (like their ability to be installed together).

(In reply to "FeRD" (Frank Dana) from comment #41)
> Naming these packages `python2-nautilus` and `python3-nautilus` is simply
> not accurate. In fact it's dangerously misleading, and can create false
> impressions (like their ability to be installed together).

Agreed. Sorry, got a bit sidetracked yesterday, but working on fixing this now. I think it would make sense to just call the binary package 'nautilus-python'.

OK, I pushed a bunch of fixes that rename the binary package back to nautilus-python and drop (and obsolete etc) the python2-/python3- prefixed subpackages. This is how it was in F27 and I believe the rename to python2-nautilus was incorrect, as it's not a Python module.

The F29 package is now built against Python 2, and F30+ is built against Python 3. If you are maintaining an extension, please check that it supports Python 3 starting with F30 and fix it up if it doesn't.

It would, of course, have been nice to make the switch already in F29, but I think it's too much to ask for all maintainers to do the switch now on short notice. Let's be a bit conservative here.

This also updates nautilus-python to the latest upstream version, 1.2.2.

I've also added nautilus-python to mclazy (that's the script I use for updating GNOME packages) which should help with make sure it gets updated regularly in the future.

nautilus-python-1.2.2-1.fc29 has been submitted as an update to Fedora 29. https://bodhi.fedoraproject.org/updates/FEDORA-2018-c01870c2fd

I've emailed a heads up about the switch to Python 3 to the devel list: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/LE7CHYY5C6TWISKOVKU3HJCU4ABEHEJL/

*** Bug 1645730 has been marked as a duplicate of this bug. ***

Thanks for the fix. The build for epel7 failed:

Error: Package: gnome-themes-standard-3.28-2.el7.x86_64 (build)
           Requires: google-noto-emoji-color-fonts

https://koji.fedoraproject.org/koji/buildinfo?buildID=1160982

Well, I tend to remove myself from ACL. I lost interest in this particular package because it takes too much time from my limited amount available to spend for an open source project. It's all said from my side, see my comments below.

nautilus-python-1.2.2-1.fc29 has been pushed to the Fedora 29 testing repository. If problems still persist, please make note of it in this bug report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2018-c01870c2fd

(In reply to Raphael Groner from comment #30)
> Christian, thanks for your deeper interest. Do you want to become a
> co-maintainer? If yes, please feel free to request and let me know your FAS
> nick to let assign ACL to you.

I was unsure whether to do that. I think having Kalev Lember maintain this package is a better choice.

> {This bug makes me sad and angry about the status of our community.}

Don't be. Stuff does not work perfectly all the time.

nautilus-python-1.2.2-1.fc29 has been pushed to the Fedora 29 stable repository. If problems still persist, please make note of it in this bug report.

Thanks, Kalev. Basil (comment 22 & 23) and others have reported downstream that nautilus-python fixes Nautilus integration for GSConnect in F29.

(In reply to Kalev Lember from comment #43)
> 
> The F29 package is now built against Python 2, and F30+ is built against
> Python 3. If you are maintaining an extension, please check that it supports
> Python 3 starting with F30 and fix it up if it doesn't.
> 
> It would, of course, have been nice to make the switch already in F29, but I
> think it's too much to ask for all maintainers to do the switch now on short
> notice. Let's be a bit conservative here.

(Also re: comment 45, announcement of the pending switch to the devel list)

Should the move from Python 2 to Python 3 in nautilus-python also be announced as a Fedora 30 Self-Contained Change, perhaps? Just for maximum visibility/tracking of the need for extension maintainers to ensure Python 3 compatibility for their extension code?

(In reply to Christian Stadelmann from comment #49)
> (In reply to Raphael Groner from comment #30)
> > Christian, thanks for your deeper interest. Do you want to become a
> > co-maintainer? If yes, please feel free to request and let me know your FAS
> > nick to let assign ACL to you.
> 
> I was unsure whether to do that. I think having Kalev Lember maintain this
> package is a better choice.

It would actually be awesome if you could help keep an eye on the package, especially now that Raphael is stepping down. I do all of GNOME packaging/updates and as such don't have much energy left to follow bugs for each package. If you want to keep a closer eye on nautilus-python I'd be glad to add you as a co-maintainer.


(In reply to "FeRD" (Frank Dana) from comment #51)
> (Also re: comment 45, announcement of the pending switch to the devel list)
> 
> Should the move from Python 2 to Python 3 in nautilus-python also be
> announced as a Fedora 30 Self-Contained Change, perhaps? Just for maximum
> visibility/tracking of the need for extension maintainers to ensure Python 3
> compatibility for their extension code?

Sure, do you want to help do that? I think I'll just leave it as is otherwise (with just the devel list announcement).

(In reply to Raphael Groner from comment #47)
> Thanks for the fix. The build for epel7 failed:
> 
> Error: Package: gnome-themes-standard-3.28-2.el7.x86_64 (build)
>            Requires: google-noto-emoji-color-fonts
> 
> https://koji.fedoraproject.org/koji/buildinfo?buildID=1160982

Thanks. Filed https://bugzilla.redhat.com/show_bug.cgi?id=1647764 for the build issue

(In reply to Kalev Lember from comment #52)
> (In reply to "FeRD" (Frank Dana) from comment #51)
> > (Also re: comment 45, announcement of the pending switch to the devel list)
> > 
> > Should the move from Python 2 to Python 3 in nautilus-python also be
> > announced as a Fedora 30 Self-Contained Change, perhaps? Just for maximum
> > visibility/tracking of the need for extension maintainers to ensure Python 3
> > compatibility for their extension code?
> 
> Sure, do you want to help do that? I think I'll just leave it as is
> otherwise (with just the devel list announcement).

Happy to, but as I'm not CLA+1 I no longer have write access to the Wiki, so there's only so far I can take it. 

I've completed https://fedoraproject.org/wiki/Changes/EmptyTemplate for the proposed change (with you listed as the owner), and I'll attach the MediaWiki source to the bug. 

(I ran it through the wiki's Special:ExpandTemplates to validate the structure, and there were no obvious issues.)

According to https://fedoraproject.org/wiki/Changes/Policy#Self_contained_changes
it would get posted as a new wiki page named
Changes/Migrate_Python-based_Nautilus_extensions_to_Python_3
(based on the title I used for the proposal), and from there it would be picked up by the Change Wrangler.

Created attachment 1503363 [details]
Fedora 30 Self-Contained Change proposal

The completed proposal template.

Nice, that looks really good! Thanks for writing that up. I'll add your name to the change proposal as well if you don't mind.

Absolutely, fine by me. Thanks!

Comment on attachment 1503363 [details]
Fedora 30 Self-Contained Change proposal

Thanks, submitted as https://fedoraproject.org/wiki/Changes/NautilusExtensionsPython3