When I upgraded fedora from 31 to 33, I found out that the base python package had been upgraded from 3.7.9 to 3.9, and that python references in virtual environment folders were now pointing to the new version of python.
There were no problems activating my python 3.7 virtual environment
[bou#bous-fed33 avguide]$ source ~/py37/bin/activate
(py37) [bou#bous-fed33 avguide]$ which python
~/py37/bin/python
However the python version was no longer 3.7.9 but 3.9, which came with fedora 33
(py37) [bou#bous-fed33 avguide]$ python -V
Python 3.9.0
Now when I tried running jupyter notebook get errors ModuleNotFoundError
(py37) [bou#bous-fed33 avguide]$ jupyter notebook --port 7777
[W 09:14:02.710 NotebookApp] Error loading server extension jupyterlab
ModuleNotFoundError: No module named 'jupyterlab'
Also get errors for other packages like pandas, numpy etc which had all been fine before.
(py37) [bou#bous-fed33 avguide]$ python
Python 3.9.0 (default, Oct 6 2020, 00:00:00)
[GCC 10.2.1 20200826 (Red Hat 10.2.1-3)] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import pandas as ps
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
ModuleNotFoundError: No module named 'pandas'
I had tried to reinstall all the packages from existing requirements.txt file and manual reinstalls as well - all failed with errors. There was also no point in reinstalling python 3.7 as it was still there.
(py37) [bou#bous-fed33 avguide]$ pip3 install --force-reinstall -r requirements.txt
[bou#bous-fed33 avguide]$ sudo dnf install python37
Package python3.7-3.7.9-2.fc33.x86_64 is already installed.
I found a relatively simple FIX after a while.
The way python versions is managed is by using symbolic links in virtual env folders. So all we have to do is find the location of existing python binary for 3.7.9 or whatever python version your virtual environment uses and update the symbolic links to point to the correct python base packages.
These are the python versions installed in my fedora OS/base.
[bou#bous-fed33 ~]$ ls -ltr /usr/bin/python3*
-rwxr-xr-x. 2 root root 15536 Sep 22 19:23 /usr/bin/python3.7
-rwxr-xr-x. 1 root root 15536 Sep 25 23:37 /usr/bin/python3.8
lrwxrwxrwx. 1 root root 9 Oct 7 00:19 /usr/bin/python3 -> python3.9 <<<
-rwxr-xr-x. 1 root root 15536 Oct 7 00:20 /usr/bin/python3.9 <<<
Note how /usr/bin/python3 points to python3.9
Locate the symbolic links in virtual environment ~/py37/bin/ folder
[bou#bous-fed33 avguide]$ cd ~/py37/bin/
[bou#bous-fed33 bin]$ ls -ltr python*
lrwxrwxrwx. 1 bou bou 16 Dec 29 2019 python3 -> /usr/bin/python3
lrwxrwxrwx. 1 bou bou 7 Dec 29 2019 python -> python3
Note how python points to python3 and python3 in turn points to operating system package /usr/bin/python3 - which after the fedora python upgrade no longer points to /usr/bin/python3.7 but to the new version of python /usr/bin/python3.9
So all we need to do is remove existing softlinks
[bou#bous-fed33 bin]$ rm python3 python
And then create new files or symbolic links python3 and python that point to python3.7 binary in /usr/bin/python3.7
[bou#bous-fed33 bin]$ ln -s /usr/bin/python3.7 python3
[bou#bous-fed33 bin]$ ln -s python3 python
Activate virtual environment and check python version is correct.
[bou#bous-fed33 bin]$ ls -ltr python*
lrwxrwxrwx. 1 bou bou 18 Dec 2 10:03 python3 -> /usr/bin/python3.7
lrwxrwxrwx. 1 bou bou 7 Dec 2 10:04 python -> python3
[bou#bous-fed33 avguide]$ source ~/py37/bin/activate
(py37) [bou#bous-fed33 avguide]$ python -V
Python 3.7.9
(py37) [bou#bous-fed33 avguide]$ which python
~/py37/bin/python
(py37) [bou#bous-fed33 avguide]$ python
Python 3.7.9 (default, Sep 22 2020, 09:19:36)
[GCC 10.2.1 20200826 (Red Hat 10.2.1-3)] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import pandas as pd
>>> quit()
We got the correct python version back for our virtual env and JupyterLab runs all right as well now.
(py37) [bou#bous-fed33 avguide]$ jupyter notebook --port 7777
[I 10:07:54.408 NotebookApp] JupyterLab extension loaded from /home/bou/py37/lib64/python3.7/site-packages/jupyterlab
[I 10:07:54.408 NotebookApp] JupyterLab application directory is /home/bou/py37/share/jupyter/lab
[I 10:07:54.410 NotebookApp] The Jupyter Notebook is running at:
[I 10:07:54.410 NotebookApp] https://bous-fed33:7777/
Hope this helps out someone running into similar problems with using their python virtual environment after base OS and/or python upgrade to a new version.
A better solution is to use pyenv, as it is specifically designed for this situation.
Pyenv will be available in your package repo... so yum search pyenv, then install.
See all available Python versions that pyenv can install for you:
$ pyenv install --list
Then pick form the list, eg. you'll see your missing Python 3.7.9. Install it to your local pyenv store, which will allow you to use it in your virtual environment:
$ pyenv install 3.7.9
You can then activate it in the directory containing your virtual env:
$ cd avguide
$ python --version
Python 3.9.0
$ pyenv local 3.7.9
$ python --version
Python 3.7.9
and it will automatically take care of you python binary links. See this tutorial and search for similar ones to get all the details.
Related
Running on Mac Big Sur 11.6.2
Using Python 3.8
Mysql 8.0.29 Homebrew
MYSQLConnection call to #database.setter, i.e. db_conn.database = my_db_name, incorrectly routes to the _mysql_connector c-extenstion, but I don not have the c extension installed, so the call raises an exception. After pip install mysql-connector-python the file WHEEL contains Root-Is-Purelibe: true and top_level.txt is missing _mysql_connector. I expect calling db_conn.database = my_db_name to execute the MySQLConnection class’ database(value) method in connection.py, not route the call to a non-existent _mysql_connector I have been unable to get pip to install the mysql-connector-python with c extension despite trying various suggestions in stackoverflow.
Sorry, I don't a reputation yet to reply in comment to Nuno-Mariz, so posting the following.
I work on the same team as #needpythonhelp, and we have nearly identical macbook pro laptops, they are not M1. We use the the same Pipfile to create a project-specific .venv. His does not get the _mysql_connector, and my .venv does (I don't remember how I got my python 3.8 version a year ago). See difference below. Could his lack of _mysql_connector have anything to do with missing CPPFLAGS or LDFLAGS when his Python version was installed (presumably built from source e.g. pyenv or annaconda)?
My system
clang --version
Apple clang version 12.0.0 (clang-1200.0.32.29)
Target: x86_64-apple-darwin19.6.0
Thread model: posix
InstalledDir: /Library/Developer/CommandLineTools/usr/bin
$ python3
Python 3.8.5 (v3.8.5:580fbb018f, Jul 20 2020, 12:11:27)
[Clang 6.0 (clang-600.0.57)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
cat .venv/lib/python3.8/site-packages/mysql_connector_python-8.0.23.dist-info/WHEEL
Wheel-Version: 1.0
Generator: bdist_wheel (0.35.1)
Root-Is-Purelib: false
Tag: cp38-cp38-macosx_10_14_x86_64
cat .venv/lib/python3.8/site-packages/mysql_connector_python-8.0.23.dist-info/top_level.txt
_mysql_connector
_mysqlxpb
mysql
mysqlx
ls -la .venv/lib/python3.8/site-packages/_mysql*
-rwxr-xr-x 1 brian staff 7876288 May 25 18:53 .venv/lib/python3.8/site-packages/_mysql_connector.cpython-38-darwin.so
-rwxr-xr-x 1 brian staff 3190548 May 25 18:53 .venv/lib/python3.8/site-packages/_mysqlxpb.cpython-38-darwin.so
needpythonhelp's system
$ clang --version
Apple clang version 11.0.3 (clang-1103.0.32.62)
Target: x86_64-apple-darwin20.6.0
Thread model: posix
InstalledDir: /Library/Developer/CommandLineTools/usr/bin
$ python3
Python 3.8.3 (default, Jul 2 2020, 11:26:31)
[Clang 10.0.0 ] :: Anaconda, Inc. on darwin
his WHEEL file has
Root-Is-Purelib: true
Tag: py2-none-any
Tag: py3-none-any
top_level.txt
mysql
mysqlx
he does not have either of these in .venv/lib/python3.8/site-packages
_mysqlxpb.cpython-38-darwin.so
_mysql_connector.cpython-38-darwin.so
Edit/Update to the above info
I did a test later today where I used pyenv to install the latest CPython 3.8.13, and built a new .venv from the same Pipfile as noted above. This .venv is like #needpythonhelp's .venv. So now I have one .venv (CPython 3.8.13) that does NOT have _mysql_connector and Root-Is-Purelib: false, etc., and another .venv (from my original CPython 3.8.5 installed a year ago) that does have it.
This is what my Pyenv install today looked like:
❯ pyenv install 3.8:latest
python-build: use openssl#1.1 from homebrew
python-build: use readline from homebrew
Downloading Python-3.8.13.tar.xz...
-> https://www.python.org/ftp/python/3.8.13/Python-3.8.13.tar.xz
Installing Python-3.8.13...
python-build: use tcl-tk from homebrew
python-build: use readline from homebrew
python-build: use zlib from xcode sdk
Installed Python-3.8.13 to /Users/brian/.pyenv/versions/3.8.13
Any ideas on how to consistently get the c-ext when I use pyenv to install new Python versions?
First, I may have more of an issue with correct environment selection. I did a fresh install of Linux Mint 19 and apt dist-upgrade... etc... and then used apt-get and pip to install pymysql, pil.intertk and pylint for both python and python3 from the cli...
All is good from cli:
~$ python3 --version
Python 3.6.5
~$ pylint3 --version
No config file found, using default configuration
pylint3 1.8.3,
astroid 1.6.0
Python 3.6.5 (default, Apr 1 2018, 05:46:30)
[GCC 7.3.0]
python3
Python 3.6.5 (default, Apr 1 2018, 05:46:30)
[GCC 7.3.0] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import pymysql
>>> import PIL
>>>
After installing VSC.... the only two selection of python environments are 2.7.12 and 3.5.2 ?
I then modified VSC settings with: "python.pythonPath": "/usr/bin/python3"
Which still shows as Python 3.5.2 64-bit within VSC
But here comes my issue that I have tried many suggestions I have found from searching with no luck...
pylint is not finding any module I install. I assume its due to the mix match of version ? But not sure how to resolve that?
When I try to specify the pylint path : "python.linting.pylintPath": "/usr/bin/pylint3"
I get an invalid path error in VSC.. but its a valid path
~$ which pylint3
/usr/bin/pylint3
Any help would be greatly appreciated....
So after some frustrating trail and error I have fixed the issue by uninstalling the Flatpak version of Visual Studio Code listed in the Linux Mint's Software Center... and installing the deb package from the official site.
After installing the deb package... the proper version of python are showing and pylint is working correctly.
I'm working on install tensorflow on my CentOS system.
I had success install miniconda in my system and created tensorflow environment.
However, I got error message while I run "source activate tensorflow".
I checked on Anaconda page and found out the reason is activate file only support bash and zsh. But my OS centOS is csh (C shell).
And I also try to add "set path " for the tensorflow environment on my ~/.cshrc file. But it looks not working, I still get ImportError while I import tensorflow.
Does anyone know how to solve this problem?
You can try the following (on CentOS 6.8 or CentOS 7):
[root#9dc1f60d1dcd ~]# csh
[root#9dc1f60d1dcd ~]# echo $0
csh
[root#9dc1f60d1dcd ~]# bash Miniconda2-4.3.11-Linux-x86_64.sh -b -p /m2
[root#9dc1f60d1dcd ~]# /m2/bin/conda install -y tensorflow
[root#9dc1f60d1dcd ~]# /m2/bin/python
Python 2.7.13 |Continuum Analytics, Inc.| (default, Dec 20 2016, 23:09:15)
[GCC 4.4.7 20120313 (Red Hat 4.4.7-1)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
Anaconda is brought to you by Continuum Analytics.
Please check out: http://continuum.io/thanks and https://anaconda.org
>>> import tensorflow
>>> tensorflow.__version__
'0.10.0rc0'
I have glibc version 2.15 on my BeagleBone Black. I want version 2.19, but I don't know how to upgrade to the newest version. opkg list-upgradable doesn't print anything. What should I do?
root#am335x-evm:/lib# ls -la | grep libc
-rwxr-xr-x 1 root root 888940 May 2 2013 libc-2.15.so
lrwxrwxrwx 1 root root 12 Mar 31 02:33 libc.so.6 -> libc-2.15.so
I know this part is not an easy task but here are few methods to upgrade package on linux embedded device.
1) Method:
Download glibc-2.19 debian package on to device (either directly using curl or download onto PC and scp to the device)
(download the debian package based on your architecture type 32/64 bit)
Use Opkg module to install the new glibc package,
opkg -f /etc/opkg.conf -d ram update
opkg -f /etc/opkg.conf -d ram install <package-name>
Note:
a) verify the opkg configuration file
b) below is sample of config file
src/gz repo <package-repository-url>
dest ram /tmp
lists_dir ext /var/opkg-lists
option overlay_root /overlay
arch all 100
arch armv7l 200
arch armel 300
2) Method:
If you have internet on beagle bone then refer below links and you can find some command format examples.
http://wiki.openwrt.org/doc/techref/opkg
http://wiki.blue-panel.com/index.php/OPKG_%28en%29
3) Method:
Download the package source files on to your linux PC and cross-compile to beagle bone.
And then scp all required files of the package(binary,config files.....)
Yum suddenly start to give the error pasted bellow
I tried to rebuild yum, but the error remains. I re-installed krb5-libs, but the error remains
How can I repair yum without reinstating Centos?
Error:
There was a problem importing one of the Python modules
required to run yum. The error leading to this problem was:
/lib64/libkrb5.so.3: symbol krb5int_push_fscreatecon_for, version krb5support_0_MIT not defined in file libkrb5support.so.0 with link time reference
Please install a package which provides this module, or
verify that the module is installed correctly.
It's possible that the above module doesn't match the
current version of Python, which is:
2.6.6 (r266:84292, Jul 10 2013, 22:48:45)
[GCC 4.4.7 20120313 (Red Hat 4.4.7-3)]
If you cannot solve this problem yourself, please go to
the yum faq at:
http://yum.baseurl.org/wiki/Faq
At my machine the issue was caused by a second libkrb5support.so distributed with PostgreSQL 5.2 / PSqlODBC. After commenting the library path in /etc/ld.so.conf.d/psqlODBC.conf and runing ldconfig -v, I can run yum again without any issue.
In my case, the path to the "wrong" library is /opt/PostgreSQL/9.2/lib/libkrb5support.so.0
Edgar.
I encountered this error after defining LD_LIBRARY_PATH environment variable. It was fixed by adding /lib and /lib64 to LD_LIBRARY_PATH.
export LD_LIBRARY_PATH=/lib:/lib64:....
Run the below command to test what all the libraries you have:
# ldd /lib64/libkrb5.so.3
And make sure that the module 'libkrb5support.so.0' is available under '/lib64' directory or having the soft ink to the files that is inside /lib64 directory. If its not there then this error is expected. So manually you have to link it again.
From my test system:
# locate libkrb5support.so.0
/lib64/libkrb5support.so.0
# ls -l /lib64/libkrb5support.so.0
lrwxrwxrwx. 1 root root 21 Aug 19 15:52 /lib64/libkrb5support.so.0 -> libkrb5support.so.0.1
# ls -l /lib64/libkrb5support.so.0.1
-rwxr-xr-x. 1 root root 46336 May 1 2012 /lib64/libkrb5support.so.0.1