Using gedit-plugins in Python virtual environments

[nael (Nathanaël Naeri)]

Hi, I’m looking for help about what appears to be an issue in the communication between two gedit plugins when gedit runs in a Python virtual environment. The virtual environment probably does not include everything that the plugins need to communicate, and I’m looking to identify what I could install in it to make the issue go away. This is probably not a bug in gedit-plugins, strictly speaking, so I decided to post here rather than on GitLab, but I could post there if it is more appropriate.

I’d like to be able to use gedit with plugins even when I start gedit from a terminal where a Python virtual environment is active, a situation that often arises at work. But this use case does not play out well: I get the following error, all my previously enabled plugins are immediately disabled except those that come by default with gedit, and they are not re-enabled when the program is started again later outside the virtual environment. All of this is very disruptive to my workflow.

Error initializing Python Plugin Loader: PyGObject initialization failed
ImportError: could not import gobject (error was: ModuleNotFoundError("No module named 'gi'"))

This error says there’s no gi module in the Python virtual environment. It is indeed installed system-site by my distribution’s package manager. This is normal (not a bug). I could give the virtual environment access to all system-site packages by creating it with the appropriate option (python3 -m venv --system-site-packages <myvenv>), but that runs contrary to the idea of isolating the virtual environment from the system Python. Instead, I can install PyGObject in the virtual environment. This is supported, provides the gi module, makes the error go away, and makes it possible to use gedit with plugins in the virtual environment…

… except for the Git plugin. This one appears to work, as far as features are concerned, but it clogs the standard error with dozens of repeated backtraces:

Traceback (most recent call last):
  File "/usr/lib/x86_64-linux-gnu/gedit/plugins/git/windowactivatable.py", line <LINE>, in <FUNCTION>
    location = msg.location
AttributeError: 'GeditFileBrowserMessageIdLocation' object has no attribute 'location'

where <LINE> is a line in the method <FUNCTION> = root_changed|inserted|deleted of the class GitWindowActivatable in the above-mentioned file. I also get the following, probably related backtraces when enabling and disabling the Git plugin in the Preferences:

Traceback (most recent call last):
  File "/usr/lib/x86_64-linux-gnu/gedit/plugins/git/windowactivatable.py", line <LINE>, in <FUNCTION>
    self.refresh()
  File "/usr/lib/x86_64-linux-gnu/gedit/plugins/git/windowactivatable.py", line 193, in refresh
    self.bus.send('/plugins/filebrowser', 'refresh')
AttributeError: 'MessageBus' object has no attribute 'send'

where <LINE> = 171|189 and <FUNCTION> = do_activate|do_deactivate in the same class.

I’m not sure what is happening here, can I please get your expert opinion?

• The Git plugin does not return those stack traces when gedit is used outside a Python virtual environment. Does it need changes to be able to run inside a virtual environment?

• The code that fails appears to be related to communication (MessageBus, bus.send) with the File Browser Plugin (GeditFileBrowserMessageIdLocation, /plugins/filebrowser). Indeed, disabling the File Browser Plugin silences those traces. But that is a useful plugin. I don’t know anything about message buses or their use in gedit/gedit-plugins. Is there anything I could install in the virtual environment to allow this communication to take place?

I hope someone can shine a light on this, thanks a lot in advance.

[nael (Nathanaël Naeri)]

I’ve not found a solution to this issue, but I thought I should share a workaround in case others encounter this issue. Two workarounds, in fact, but the first one is unsatisfactory in my opinion:

1. Install PyGObject in the virtual environment and disable the File Browser Plugin in gedit, as mentioned in my original post.

2. Install Vext in the virtual environment. It is a Python package, available on PyPI, that makes it possible to access certain system-wide packages from within a virtual environment. In this case, we want to access the system-wide gi package, so we install vext.gi in the virtual environment:

   pip3 install vext.gi
   

   After installation, run vext --check gi.vext to test that the import gi.repository statement works. See vext --help for more options.

   The miscommunication reported between the Git and the File Browser plugins doesn’t appear to occur when using Vext.