Sorry, I realized I forgot to say something important: Never login to the GUI as root.
1 Like
I don’t care, I am used to such risk. A new user does not have the problem either.
Then how can you expect anyone else to care if you don’t?
No one can help if you don’t tell us what else you’ve done that you should not have done. Doing things like that apparently caused your issue.
Something about this maybe?
Sorry, “I don’t care” means that I am not afraid of logging as root (because I have backup).
The problem is in my user. Not in ‘~/ .config’. Not in Gnome extensions.
In Logs, I can see
ModuleNotFoundError: No module named 'gi´
import gi
File "/usr/bin/gnome-tweaks"
Also, gnome-tweaks does not work any longer in Terminal and the error message is:
File "/usr/bin/gnome-tweaks", line 13, in <module>
import gi
ModuleNotFoundError: No module named 'gi'
So it is a Python environment problem or version problem.
Did someone use sudo pip or similar?
Also … this thread at least presents as alike to this one:
Yes conda is involved (and pip as well).
That didnt answer the main question - did you use sudo with one of those python package managers at some point?
Well that, and, the general question around this:
Your virtual environments are where you should do your development things…
We are technically not interested in how gnome-tweaks functions there … we care more about regular use - ‘outside of’ those environments.
(However you abuse your virtual environment is up to you. If you break it make a new one.)
I am quite sure I did not use sudo pip for my Python stuff. My Python environment should not affect the way Gnome launches Tweaks.
My Manjaro is up to date now. If I had used sudo pip to modify the system Python, my modification would have been crushed.
You’re right, it shouldn’t. However, it is.
You already have python-gobject installed as a dependency of gnome-tweaks, but since you installed Python packages locally instead of setting up a virtual environment, it’s looking for it there.
Did I modify my Python with pip outside a virtual environment? Maybe.
Trying now to modify, I get the neat error message:
alba@mac2011-manjaro% pip install gi
error: externally-managed-environment
× This environment is externally managed
╰─> To install Python packages system-wide, try 'pacman -S
python-xyz', where xyz is the package you are trying to
install.
So I doubt I modified, unless the security net was installed very recently.
I try this
alba@mac2011-manjaro% sudo pacman -S python-gobject
warning: python-gobject-3.46.0-1 is up to date -- reinstalling
No improvement.
I don’t see how I could break the Python used by Gnome.
By not caring about signing in as root and then running pip install, maybe ?
(or … something similar. That only comes to mind because of the things mentioned here.)
I logged as root just to launch Tweaks in Activities. I normally never do this.
Now, if I do
/usr/bin/python -c 'import gi'
I have no error, while I have the gi error in Logs if I launch Tweaks from Activities.
This shows that Gnome does not use the same Python that is availabe to me.
From /usr/bin/gnome-tweaks :
import gi
gi.require_version("Gtk", "3.0")
gi.require_version("Handy", "1")
I/usr/bin/gnome-tweaks works in Terminal (after exiting any custom env). Thus Python is not broken.
Something is broken in my session but it is not Python. It is something that disturbs the way Python is called.
In Logs, maybe related:
ImportError: cannot import name '_gi' from partially initialized module
File "/usr/lib/python3.11/site-packages/gi/__init.py__", line 40
Fule "/usr/lib/lollypop/lollypop-sp", line 19
I have improved something: I could make the MyTweaks launcher work with
Exec=/usr/bin/python /usr/bin/gnome-tweaks
hence it may be just a path-to-Python problem, caused by miniconda, that I had installed with Add/Remove software (AUR).
miniconda3 disturbs Python path, in Terminal and Activities.
This can be avoided in Terminal with conda deactivate and in Activities by uninstalling miniconda3 or less radically by copying
/usr/share/applications/org.gnome.tweaks.desktop to ~/.local/share/applications/mytweaks.desktop and replacing in the new file Exec=gnome-tweaks by Exec=/usr/bin/python /usr/bin/gnome-tweaks.
In Activities, search Tweaks and click the second icon.
I dont use it to know whether its a packaging issue or just miniconda.
Either way not gnomes fault.
Heres the AUR page for that PKGBUILD:
https://aur.archlinux.org/packages/miniconda3
Which doesnt appear to manually move any executables or mess with PATH, so … my guess is its up to miniconda.
https://docs.conda.io/projects/miniconda
With a freshly created user, after conda init zsh, I see the problem in Terminal, not in Activities. I must have messed something in Gnome configuration.
I found it today. The problem was lying in ~/ .bashrc created by conda init.
Since I don’t use bash, I just had to remove .bashrc. To clean a cluttered .bashrc, something like conda init --reverse may help. conda has no man page…
This proves that Gnome shell reads .bashrc, which I was not aware of, and looks weird to me. Gnome shell configuration files are scattered and changing over the years. This does not help.
As zsh is now Terminal defaut shell, the problem can be avoided in the first place when installing conda, by doing conda init zsh, not conda init.
The Manjaro installer only installs Conda system files. Conda installation requires some user configuration steps, which are error prone.
.bashrc is one of the most common configuration files I could think of.
Though … it may be a bit odd if its being read when you dont use bash.
(maybe this is like plasma … where the login shell and the interactive shell are different?)
(( only because zsh was implemented, but that causes errors, so the login shell must remain bash, with zsh applied via konsole profiles ))
Exactly, that is what caught me.
This topic was automatically closed 36 hours after the last reply. New replies are no longer allowed.