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?
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.
To add to @Railslide 's answer:
In your /usr/lib/gedit/plugin
search for your plugin file (eg bracketcompletion.plugin
) and change Loader=python3
to Loader=python
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 *
eg 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
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 (eg bracketcompletion.plugin
) and change Loader=python3
to Loader=python
Unfortunately, this workaround doesn't work for all the plugins .
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).
(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
~/miniconda3/bin
from $PATH
, /usr/bin/gedit
), giving it all arguments, ~/miniconda3/bin
in our $PATH
. With these few lines in .bashrc
, one can simply call gedit <arguments>
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.
The technical post webpages of this site follow the CC BY-SA 4.0 protocol. If you need to reprint, please indicate the site URL or the original address.Any question please contact:yoyou2525@163.com.