1

My issue is similar to what was described here 3 years ago, but in my case on Arch Linux 5.3.7. Not certain this is the right place to ask though.

Motivation: I want to run ibus-setup to correct what I believe is the key binding CTRL-SHIFT-E being hijacked by my GTK apps (Firefox + LibreOffice) to open an annoying emoji-picker window. Concretely I want to suppress what I think might be a default GTK key binding.

I thought I might try that with ibus-setup. 

$ ibus-setup
Traceback (most recent call last):
  File "/usr/share/ibus/setup/main.py", line 33, in <module>
    from gi import require_version as gi_require_version
ModuleNotFoundError: No module named 'gi'

I found that "gi" is part of package extra/python-gobject which I installed, along with extra/python2-gobject and extra/python-gobject2 for good measure.

I ran $ ibus-setup again both in my global Python 3.7.4 env and in a Python 2.7.16 (pyenv) virtual environment, although the Python RTE outside the process(es) launched by ibus-setup should not matter. Same error.

/usr/share/ibus/setup/main.py is python2 code and I could not see anything blatantly wrong with how gi is invoked.

I even tried the small python snippet here to check that gi is correctly imported when called from python on my box, both in Python 3.7 and 2.7. Worked well, which means that gican be correctly imported from python console.

I'm stumped. Any pointer anyone ?

Cbhihe
  • 511
  • 9
  • 24

3 Answers3

0

Assuming your system has python2 installed, a possible solution is perhaps alias python=python2 in your shell, then try ibus-setup again.

I encountered the same issue today on Ubuntu 18.04. I was in a conda environment (py3.6). After deactivating the environment, it works. Using which python and python --version, I believe it invoked python2.7 from usr/bin/python.

Shern
  • 712
  • 1
  • 8
  • 20
0

whereis ibus-setup

example: vim /usr/bin/ibus-setup

change exec python3 /usr/share/ibus/setup/main.py $@ ===>> exec python2/usr/share/ibus/setup/main.py $@

tianwj
  • 1
  • 2
0

The solution lied in either:

  1. removing your virtual environment be it Conda, Pyenv, or otherwise, although that hack does not represent a viable solution, if you (as I) rely on virtual environments for your work. This is because virtual environments introduce new default paths for the default Python to execute.

  2. or, provided your PYTHON environment variable is not set, modifying the /usr/bin/ibus-setup shell script so the last line reads:
    exec "${PYTHON:-/usr/bin/python3}" /usr/share/ibus/setup/main.py "$@"

  3. or specifying the PYTHON environment variable when launching ibus-setup from terminal:

    > PYTHON=/usr/bin/python ibus-setup

This 3rd approach is probably the most flexible way of dealing with the OP's issue. Doing so circumvents the fact that the new default path for Python 3.x in my case, with pyenv, is $HOME/.pyenv/shims/python. Note that the redefined path is restricted to the spawned shell if any. Also in my case /usr/bin/python points to /usr/bin/python3 by means of a symbolic link.

HTH

Cbhihe
  • 511
  • 9
  • 24