8

I tried to add some plugins in gedit 3.10.4 on ubuntu 14.04LTS and some errors occured when I try to activate those plugins in gedit:

(gedit:20686): libpeas-WARNING **: Error initializing Python Plugin Loader: PyGObject initialization failed ImportError: could not import gobject (error was: ImportError("No module named 'gi'",))

(gedit:20686): libpeas-WARNING **: Please check the installation of all the Python related packages required by libpeas and try again

(gedit:20686): libpeas-WARNING **: Loader 'python3' is not a valid PeasPluginLoader instance

(gedit:20686): libpeas-WARNING **: Could not find loader 'python3' for plugin 'bracketcompletion'

And I see, on ged

plugin loader 'python3' was not found

Does anyone have an idea from where the problem could come?

NoDataDumpNoContribution
  • 10,591
  • 9
  • 64
  • 104
Julien LM
  • 81
  • 1
  • 4

4 Answers4

4

I had this very same error with a different plugin (reST). The problem the error was caused by was that I had run it from the command line when a virtual environment was active. For this reason Python3 did not use (and find) the system libraries.

Solution: I ran gedit just normally from the GUI (or after deactivating the virtualenv in the Terminal), and the editor and the plugin just loaded fine. Double-check if you have a similar cause.

Otherwise you probably really have to check on what the error message says: Whether all "related packages required by libpeas" are installed. See details of package libpeas-1.0-0 for Trusty.

Peterino
  • 15,097
  • 3
  • 28
  • 29
3

To add to @Railslide 's answer:

  1. In your /usr/lib/gedit/plugin search for your plugin file (e.g. bracketcompletion.plugin) and change Loader=python3 to Loader=python

  2. If this still returns an error - likely because it doesn't match python3 syntax: Use the command 2to3 as follows:

    cd python_directory/
sudo 2to3 -f all -w *

e.g. for gedit-latex-plugin...

cd /usr/lib/gedit/plugins/
sudo sed -i 's/python/python3/g' latex.plugin # only if you haven't already replaced python->python3
cd latex/
sudo 2to3 -f all -w *

Then this fixes the plug-in by replacing python2.x code with python3 code

Related

Community
  • 1
  • 1
Alexander McFarlane
  • 10,643
  • 9
  • 59
  • 100
0

It's a gedit bug, see https://bugs.launchpad.net/ubuntu/+source/gedit/+bug/859089

As a workaround, in your /usr/lib/gedit/plugin search for your plugin file (e.g. bracketcompletion.plugin) and change Loader=python3 to Loader=python

Unfortunately, this workaround doesn't work for all the plugins.

Railslide
  • 5,344
  • 2
  • 27
  • 34
  • 3
    Thanks for your answer but it is not changing anything... Now the error is "pluging loader 'python' was not found" – Julien LM Mar 10 '15 at 14:11
0

I've encountered essentially the same problem today, though with the code-comment plugin. In my case, the issue only showed up when gedit was executed from the command line, similarly to @Peterino (though no virtual environment had actually been explicitly set up). Everything was fine otherwise.

The reason why this happened seems to be linked to the fact that I have set up my $PATH in .bashrc in such a way that python3 corresponds to a local anaconda/miniconda installation. An unwanted side effect is that, when launched from the terminal, gedit then actually picks the local miniconda install instead of /usr/bin/python3.X. (Checked by temporarily moving the miniconda folder elsewhere or login-in as another user).

Possible fixes

(Though I'm still not completely satisfied with either of them).

Putting this in .bashrc works:

export CONDAPATH=$HOME/miniconda3/bin
export PATH="$CONDAPATH:$PATH"
# ^ put these two lines instead of the original miniconda export.

# __ : naming convention for private functions
__geditfix() {
    export PATH=$(echo $PATH | sed -E "s|:$CONDAPATH\|$CONDAPATH:||g"); # remove conda from the PATH environment variable, using RegEx
    gedit "$@"; # call gedit, giving it all arguments
    export PATH="$CONDAPATH:$PATH"; # add conda to the PATH environment variable
} # Using a function rather than an alias, so that the filename is given to gedit, as it should and not to setconda().

alias gedit='__geditfix' # So that we can run our fix simply via: gedit <arguments>.

What this ^ does is to create an alias for gedit, using a function which actually

  • 1) removes ~/miniconda3/bin from $PATH,
  • 2) runs gedit (/usr/bin/gedit), giving it all arguments,
  • 3) puts back ~/miniconda3/bin in our $PATH.

With these few lines in .bashrc, one can simply call gedit <arguments>

  • the plugins work since gedit will pick python from /usr/bin/,
  • python, jupyter-notebook, conda, and the like from miniconda can still be directly accessed without problem

btw, this helped: https://stackoverflow.com/a/23134318/452522 (environment variables substitution in sed)

Alternative solution: install this v:

conda install -c conda-forge pygobject

As could be guessed from the terminal outputs it was missing when using the miniconda python3 install.

Alex
  • 155
  • 1
  • 13
  • As of today, my favourite solution is to now instead use a virtual environment that I *only* activate when I explicitly want to work with python or jupyter in that specific terminal. I chose `venv`, see https://docs.python.org/3/library/venv.html#creating-virtual-environments You can create a new environment (only needs to be done once) e.g. via: `python3 -m venv /yourpath/to/new/virtual/environment` Then to activate it, simply do: `source /yourpath/to/new/virtual/environment/bin/activate` And to deactivate it, simply type `deactivate`. – Alex Nov 07 '19 at 14:40