My Matplotlib backend keeps reverting to TkAgg. This is a problem because in the Windows Subsystem for Linux (WSL), you can't do GUI stuff, and so I get the error
TclError: no display name and no $DISPLAY environment variable
I've tried adding a matplotlibrc file to /home/<user>/.config/matplotlib (in the Windows filesystem, this is C:\Users\<user>\AppData\Local\lxss\home\<user>\.config\matplotlib).
My matplotlibrc looks like this
backend : Agg
However, if I do this
$ cd /home/<user>/.config/matplotlib
$ ls -A
nothing shows up.
When I try
$ python
>>> import matplotlib
>>> matplotlib.get_backend()
'TkAgg'
so clearly it's not setting the backend to Agg. Why not?
Update:
I've figured out that putting backend : Agg in C:\Users\<user>\AppData\Local\lxss\home\<user>\.config\matplotlib\matplotlibrc changes the backend in Windows Python only, leaving Linux Python as TkAgg. Which is odd, because Windows Python should only be using C:\Users\<user>\AppData\Local\Enthought\Canopy\User\Lib\site-packages\matplotlib\mpl-data\matplotlibrc, right?
I figured it out. I had created the matplotlibrc file using Windows - this is why it didn't show up when I tried $ ls -A in bash. So I did this instead (after deleting the Windows-created file):
$ cd /home/<user>/.config/matplotlib
$ touch matplotlibrc
$ echo "backend : Agg" > matplotlibrc
(touch matplotlibrc creates an empty matplotlibrc file)
This did the trick, and my Windows python matplotlib's backend was left as Qt4Agg.
Here it is on one line for copy/paste:
cd /home/<user>/.config/matplotlib; touch matplotlibrc && echo "backend : Agg" > matplotlibrc
Related
I am trying to run some code inside a server. In that server, we use docker images to create notebooks inside directories, with commands like:
docker run -it --gpus "device=1" -p 8886:8886 -v /folder/directory:/workspace/work --name container-name --shm-size=60g --ulimit memlock=-1 --ulimit stack=67108864 --rm imageid jupyter notebook --port=8886 --ip=0.0.0.0 --allow-root --no-browser
Once created the notebook with an image, we have two different environments with two different python versions in the folder that were designed to execute the code inside /folder/directory: venv3.6 and venv3.7.
Even if I didn't create them, I am confident that the environments worked at some point (there are checkpoints obtained from the execution of the code by a colleague that worked on it before me). However, it must have been messed up with at some point, maybe after some modifications on the libraries of the docker image.
The problem is that, whenever I try to activate venv3.7 by using source ./venv3.7/bin/activate and run a script with python script_name.py, the python version that is executed is not 3.7, but rather 3.6.10. When going into /venv3.7/bin/activate and trying to access or download the python, the python3 or the python3.7 files, they cannot be accessed, moved or activated (i.e., if I enter /venv3.7/bin/python3.7 on the terminal, I obtain the file not found error).
When the environment is activated:
root#XXXX:/workspace/work/path# which python
/opt/conda/bin/python
root#XXXX:/workspace/work/path# source ./venv3.7/bin/activate
(venv3.7) root#XXXX:/workspace/work/path#
Following this stackoverflow post, I make the following comprobations
(venv3.7) root#XXXX:/workspace/work/path# python -V
Python 3.6.10 :: Anaconda, Inc.
(venv3.7) root#XXXX:/workspace/work/path# echo $PATH
/workspace/work/path/venv3.7/bin:/usr/local/nvm/versions/node/v15.0.1/bin:/opt/conda/bin:/opt/cmake-3.14.6-Linux-x86_64/bin/:/usr/local/mpi/bin:/usr/local/nvidia/bin:/usr/local/cuda/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/local/ucx/bin:/opt/tensorrt/bin
(venv3.7) root#XXXX:/workspace/work/path# which python
/opt/conda/bin/python
(venv3.7) root#XXXX:/workspace/work/path# alias
alias egrep='egrep --color=auto'
alias fgrep='fgrep --color=auto'
alias grep='grep --color=auto'
alias l='ls -CF'
alias la='ls -A'
alias ll='ls -alF'
alias ls='ls --color=auto'
Which shows that the path is added correctly and there is no alias for python that could be messing with the activation but, still, python command uses the version from /opt/conda/bin/python instead of /workspace/work/path/venv3.7/bin
I also have checked that the path VIRTUAL_ENV in activate script (venv3.7/bin/activate) is correct.
I noticed that the directory: /venv3.7/pyvenv.cfg contains:
home = /usr/bin
include-system-site-packages = false
version = 3.7.5
And when I go to the directory /usr/bin, which should contain the python in which the environment is based, it only has python2.7 files. Could that mean that, when the first directory in $PATH is followed, no valid version of Python is found?
My guess is that the python (python, python3, python3.7) files were symlinks that were broken because the python version changed in /usr/bin. However, I don't want to risk to update the version of python in that directory, because it would probably change the default python in /opt/conda/bin/python instead, and I don't know much about docker images. Do you think it would work? In that case, how would I do it?
As additional info, the python files inside venv3.6/bin seems to work well (it can be executed and copied), but maybe because /venv3.6/pyvenv.cfg leads to the default python instead (in /opt/conda/bin/python). Also, after asking the original creator of the code, she doesn't know how to solve this issue either.
I need the environment to work, and recreating it is problematic, since many libraries were downloaded from different places (it was delicate work).
What do you suggest?
EDIT
I have tried recreating the environment with the python version I need (3.7.5). Do you know of an easy way to install the same libraries than in the other environment, considering that I can't activate it?
I was thinking to use the folders with the libraries located in /venv3.7/lib, but It is not straight forward. Any idea on how to do it?
Also, would you recommend me to create the new environment with virtualenv (to have a separate python version) or, rather, with anaconda?
Thank you so much for reading me!
After checking the python3.7 file in the environment:
root#XXXX:/# cd workspace/work/path/venv3.7/bin
root#XXXX:/workspace/work/path/venv3.7/bin# stat python
File: python -> python3.7
Size: 9 Blocks: 0 IO Block: 4096 symbolic link
Device: XXXX Inode: XXXX Links: 1
Access: (XXXX) Uid: ( 0/ root) Gid: ( 0/ root)
Access: 2022-12-06 10:31:18.165001523 +0000
Modify: 2022-05-20 12:28:37.481538688 +0000
Change: 2022-05-20 12:28:37.481538688 +0000
Birth: -
root#XXXX:/workspace/work/path/venv3.7/bin# stat python3.7
File: python3.7 -> /usr/bin/python3.7
Size: 18 Blocks: 0 IO Block: 4096 symbolic link
Device: XXXX Inode: XXXX Links: 1
Access: (XXXX) Uid: ( 0/ root) Gid: ( 0/ root)
Access: 2022-12-06 10:31:18.165001523 +0000
Modify: 2022-05-20 12:28:37.481538688 +0000
Change: 2022-05-20 12:28:37.481538688 +0000
Birth: -
It became obvious that, as stated in the post, /usr/bin should be the directory where python3.7 should be installed. That means the problem could be solved by installing it in that folder.
As I didn't know that was the default folder for the Python installation, I tried installing python from source as exposed in several guides. However, even if now the environment started accessing python3.7 in the folder, that installation didn't work either.
So I just tried apt-get install python3.7. It took around 10 seconds and, when I tried the code again, it worked!
Next time, when your environments fails because the wrong python version is executed, and the aliases and $PATH are right (see this post for more details), just remember to check where the python files in the environment point to and verify that the python installation is correct!
I hope this is useful for you.
I would like to add my site-packages directory to the PYTHONPATH variable, so I can import modules which are stored there to use them in scripts in interpreter. My default shell is zsh, and the OS is macOS Monterey, version 12.6.
I have tried to open the ~/.zprofile in nano editor from my terminal, adding the path I need, and restarting my terminal, but it did not help to solve the issue. After restarting the terminal, I tried to run following commands:
narynaa#Narynas-MacBook-Pro ~ % echo ~/.z.profile
/Users/narynaa/.z.profile
narynaa#Narynas-MacBook-Pro ~ % cat ~/.zprofile
# Set PATH, MANPATH, etc., for Homebrew.
eval "$(/opt/homebrew/bin/brew shellenv)"
export PYTHONPATH="/opt/homebrew/lib/python3.10/site-packages"
The path I need is stored inside the ~/.zprofile file now, but the problem is not solved.
Thank you for your help!
I have latest GVim (v8.2) 64-bit and Miniconda Python 3.8.5 64-bit installed on Windows 10. I am working in the virtual environment da38 and included the following two lines in my $HOME\_vimrc file to point to the correct python interpreter and libraries for this environment:
set pythonthreehome=$HOME\miniconda3\envs\da38
set pythonthreedll=$HOME\miniconda3\envs\da38\python38.dll
Both :echo has('python3') and :echo has('python3_dynamic') return 1. I have installed Vim plugin dense-analysis/ale for python linting, and installed flake8 and black packages in da38 using conda install flake8 black. And I added the following lines in $HOME\_vimrc to configure this plugin:
let g:ale_linters = {'python': ['flake8']}
let g:ale_fixers = {'*': [], 'python': ['black']}
let g:ale_fix_on_save = 1
But the plugin does not show any error on a python file that has many by design: running flake8 test.py on command prompt returns a lot of errors. :ALEInfo repeats these two lines several times:
(executable check - failure) flake8
(finished - exit code 1) 'cmd /s/c "cd /d "C:\Users\Admin\Desktop" && black - < C:\Users\Admin\AppData\Local\Temp\VIBA694.tmp\test.py"'
I am wondering if somehow the correct python path is not being passed to Vim, but cannot figure out what else to do. Any help is much appreciated.
Thanks
UPDATE:
I think I narrowed down the problem. Linter plugin fails when I open test.py with vim from the desktop icon, but works if I first activate the virtual environment with conda activate da38 and then start vim on command prompt. I guess the desktop vim does not see the virtual environment, where the two packages flake8 and black are installed. So I believe the problem is how to add the appropriate python environment to the desktop vim. I should add the vim-conda plugin did not help.
UPDATE #2:
I managed to get vim-conda plugin working with gvim, and now the linter plugin works as expected.
UPDATE #3:
One can avoid using a plugin and instead hard-code the environment path in _vimrc (for windows):
let venv = 'da38'
let mypath = 'C:\Users\Admin\miniconda3\envs\' . venv . ';'
\ . 'C:\Users\Admin\miniconda3\envs\' . venv . '\Scripts;'
\ . 'C:\Users\Admin\miniconda3\envs\' . venv . '\Library\bin;'
let $PATH = mypath . $PATH
This code sticks the env path in front of default $PATH.
I tried to set up GitStats but I can't seem to get it working on Windows 10 with Git Bash
I've added an environment variable to "C:\gnuplot\bin" for Gnuplot
Gnuplot installed:
$ gnuplot --version
gnuplot 5.2 patchlevel 7
GitStats:
$ python gitstats ../ ../stats/
'C:\gnuplot\bin' is not recognized as an internal or external command,
operable program or batch file.
[0.04700] >> C:\gnuplot\bin --version
gnuplot not found
How can I get it working?
The gitstats scripts includes:
# By default, gnuplot is searched from path, but can be overridden with the
# environment variable "GNUPLOT"
gnuplot_cmd = 'gnuplot'
if 'GNUPLOT' in os.environ:
gnuplot_cmd = os.environ['GNUPLOT']
That means you need to set GNUPLOT to the gnuplot executable, not its parent folder (bin).
set GNUPLOT=C:\gnuplot\bin\gnuplot.exe
I encountered and solved this problem earlier this day and now I run into something similar but in another context.
When I fire up python (2.7) in my mac Terminal (Mac OS Lion) and do
import oursql
everything is fine.
When I do the same within a python script in the Aptana IDE I get the following error.
Traceback (most recent call last):
File "/Users/salah/Documents/Aptana Studio 3 Workspace/pubmap/src/scripts/parse_all_dblp_authors.py", line 10, in <module>
import oursql
ImportError: dlopen(/Library/Python/2.7/site-packages/oursql.so, 2): Library not loaded: libmysqlclient.18.dylib
Referenced from: /Library/Python/2.7/site-packages/oursql.so
Reason: image not found
This is the same error as in the problem above which I used to solve by adding
PATH=${PATH}:/usr/local/mysql/bin
export DYLD_LIBRARY_PATH="$DYLD_LIBRARY_PATH:/usr/local/mysql/lib/"
to .bashrc and
if [ -f ~/.bashrc ]; then
source ~/.bashrc
fi
to .bash_profile.
Why does this have no effect on Aptana? By the way Aptana is a derivate of eclipse so everything relevant to eclipse should be relevant to Aptana, too - at least I think so...
Edit:
A suggestion by Peter in his answer below brought me a possible solution. Just set the path right into the interpreter Options of Python in Aptana/Eclipse/Pydev. See the following Screenshot:
It's been a while since I used Pydev, but the Pydev docs on configuring the interpreter are probably worth a look.
Python IDEs usually let you configure the environment python is run in when you run from the IDE.
Also, having .bashrc change your $PATH will only change the environment variable for bash sessions. Unless you run Aptana from bash changing your .bashrc won't change the envirnment variables Aptana gets. See setting-environment-variables-in-os-x.
Aptana Studio does not read .bashrc. However it does include other files in the following order:
if [ -f /etc/profile ] ; then . /etc/profile; fi
if [ -f ~/.bash_profile ] ; then . ~/.bash_profile;
elif [ -f ~/.bash_login ] ; then . ~/.bash_login;
elif [ -f ~/.profile ] ; then . ~/.profile;
[[ -f ~/.aptanarc ]] && . ~/.aptanarc
Cheers,
Max