I tried the solution #yum---no module named yum and "No module named yum" with Python 2.7 but didn't help,it sounds like the yum module is not a stock Python module and need to build yum against your Python 2.7 install,can anyone provide guidance on how to do this?
machine details:
[usernames#machine]$ cat /etc/*elease
LSB_VERSION=base-4.0-amd64:base-4.0-noarch:core-4.0-amd64:core-4.0-noarch:graphics-4.0-amd64:graphics-4.0-noarch:printing-4.0-amd64:printing-4.0-noarch
Oracle Linux Server release 6.6
Red Hat Enterprise Linux Server release 6.6 (Santiago)
Oracle Linux Server release 6.6
Error:-
There was a problem importing one of the Python modules
required to run yum. The error leading to this problem was:
No module named yum
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.7.12 (default, Aug 11 2016, 12:02:22)
[GCC 4.4.7 20120313 (Red Hat 4.4.7-11)]
If you cannot solve this problem yourself, please go to
the yum faq at:
http://yum.baseurl.org/wiki/Faq
It appears what got clobbered was the system Python in /usr/bin, that knows where to find the python modules and shared objects installed by RHEL. So you need to reinstall RHEL python rpms, not just yum.
RHEL uses /usr/bin/python for many of it's utilities. yum is a Python (wrapper) script.
It looks like you are using RHEL 6. So /usr/bin/python must be 2.6. That's what RHEL 6 shipped with. (For RHEL 7 it needs to be 2.7.5)
So, to fix things you need to reinstall the system Python from the RHEL rpms. For the system to work correctly, /usr/bin/python can't be an arbitrary version of Python.
The yum rpm will just reinstall the yum files to the original path but you need the RHEL /usr/bin/python which is loading the modules from the correct directories. The rpm will not install the module in the Python sense. Also, there are many other modules with shared library dependencies for things like DBus interfaces.
So obtain the RHEL python-* rpms for your release. You'll need to download them, or use the ISO/DVD. rpm by itself doesn't know how to access software repos over the network that's yum's job so you have to do it manually.
Alternatively if you have another system running the same version of RHEL you could copy files over. You can use rpm -Va to get a list of all files that belong to rpms that have been modified. There are a number of files that get modified during normal operation.
(Moral of the story, don't overwrite /usr/bin/python, /usr/bin/python2. RHEL (and other platforms, Fedora, etc.) depend on the system python to work correctly.)
Well, assuming rpm is not broken - you could do something like this:
First:
rpm -q yum
for retrieving installed ( but broken ) yum package. For example on my Centos7 i get next result: yum-3.4.3-154.el7.centos.1.noarch.rpm
But that's not all. You should remove part between .el7 and noarch. Then, you can proceed to second step
Second:
rpm -qpR <yum package name>
or:
rpm -qR yum
for getting yum dependecies list.
And the last one:
rpm -Uvh <packagenames>
Apparently you replaced the system version of Python.
Don't do that. Use virtualenv, pip, and/or other tools to run custom versions of Python when you need them.
Try to put back the official distro Python installation.
Related
During the past years, I have installed many Python libraries with various Python versions. To make them ready to work immediately, I installed them blindly without control. Currently they're causing problems when I tried to install pynest which invokes numpy, scipy and matplotlib. After struggling, I am going to clean and reinstall Python and the libraries.
After investigation, I found Python 2.5/2.6/2.7/3.2 on my system, and each of them has some copies or other things at: (my OS == Mac OS X 10.7.5 Lion)
/Library/Frameworks/
/opt/local/Library/Frameworks/
/opt/local/bin/
/Applications/
/usr/local/bin/
/usr/bin/
/System/Library/Frameworks/
I know I'm crazy to have these. Now I have removed all these except the things in /System/Libarary/Frameworks (I never remove any thing from /System/Library/). After the clean work, which python now gives /usr/bin/python which links to /System/Library/Frameworks.
Now, is it a clear environment for me to reinstall python? How to double check that there's no other versions existing? How should I reinstall them to guarantee that they and their libraries won't be everywhere and have many copies again?
I want to install a clean Python 2.7 onto a proper location, and make my system know exactly where it is and never install any libraries somewhere else. Please give me some advice that how to manage it like in a professional way.
For your information, here is my current $PATH, I think it should be modified:
/opt/local/bin:/opt/local/sbin:/opt/nest/lib/python2.7/site-packages:/usr/local/lib/python2.7/site-packages:/Library/Frameworks/Python.framework/Versions/2.7/bin:/usr/texbin:/Library/Frameworks/Python.framework/Versions/3.2/bin:/usr/bin:/bin:/usr/sbin:/sbin:/usr/local/bin:/usr/texbin:/Library/Frameworks/Python.framework/Versions/3.2/lib/python3.2/site-packages/django/bin:/usr/X11/bin:/opt/local/bin:/opt/local/sbin:/usr/local/lib/python2.7/site-packages:/Library/Frameworks/Python.framework/Versions/2.7/bin:/Library/Frameworks/Python.framework/Versions/3.2/bin
Please let me know If you need more information. Thank you!
UPDATE:
I'm rethinking profoudly why it becomes so crazy. I believe it's because I installed things via:
easy_install / macports / homebrew / fink / pip sometimes;
.dmg sometimes;
.pkg sometimes;
compile source code sometimes;
and they made things at different locations. I wonder what's the mechanism behind these ways? How do they choose target location? How to prevent them from messing things up?
Why did it get messed up?
There're a couples of different way to install Python, as the update of OP says, and they locate files in different locations. For example, macports puts things into /opt/local/, while homebrew puts things into /usr/local/. Also, Mac OS X brings a few python versions with itself. So, if you install python many times via different ways, you will get many python versions existing independently on your system.
What problem does it cause?
I don't know exactly. I guess the problem is that if you have many versions of python, then which one to use and where to find packages will be determined by the path order in your system PATH and the PYTHONPATH respectively. So you may lose control of where to install python modules. Consider that if you run sudo python setup.py install to install a module (it finds python by the root's PATH) and then try to import the module by python -c "import it" (this time it finds python by your PATH), maybe something will go wrong. This is my guess, I didn't validate it. But in my own case, something did go wrong.
How to avoid this?
I think the principle would be that be aware of that different ways and tools install things independently to different locations, so use them mindfully.
Unless you intend to, don't install the same thing twice via different
ways. (If you intend to do it for python, you might want to check out virtualenv)
Keep an eye on the path order in your PATH and consider if it's
correct.
When installing modules, be clear which python (or pip) is
running and where the module is installed.
So, how did I solve my own case?
Since it had been messing up already and seemed to be very hard to cure, so finally I solved this question by a full OS re-installation, and started to follow the DOs-and-DONTs above. For the installation of the scientific environment with python (numpy/scipy/matplotlib, which had shown problems to make me ask this question), I found this tutorial was extremely helpful. So, problem solved finally.
Here is what was confusing me and how I solved it.
$ which python
/usr/bin/python
$ which python3
/usr/local/bin/python3
$ ls /usr/local/bin/python
ls: /usr/local/bin/python: No such file or directory
So notice I didn't have a HomeBrew installation of python2.7, but did have the python3 installation. The version under /usr/bin/python is using the system default. You can tell based on the module search path:
$ /usr/bin/python
Python 2.7.10 (default, Feb 7 2017, 00:08:15)
[GCC 4.2.1 Compatible Apple LLVM 8.0.0 (clang-800.0.34)] on darwin
`enter code here`Type "help", "copyright", "credits" or "license" for
more information.
>>> import sys
>>> sys.path
['', '/Library/Python/2.7/...
Notice the '/Library/Python'... that's Mac OS's version of python. But I want to stay strictly on a user installed version (i.e. HomeBrew).
So here's what I did to fix this:
$ brew install python
...
Warning: python 2.7.13 is already installed, it's just not linked.
You can use `brew link python` to link this version.
$ brew link --overwrite python
$ which python
/usr/local/bin/python
$ python
Python 2.7.10 (default, Feb 7 2017, 00:08:15)
[GCC 4.2.1 Compatible Apple LLVM 8.0.0 (clang-800.0.34)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> import sys
>>> sys.path
['', '/usr/local/Cellar/python/2.7.13...
Its no longer /Library/.. but /usr/local.
Now its finding all of my pip installed modules! Problem solved!
UPDATE:
After updating brew to version 1.5.4, it seems the symbolic links were removed. And now you have to add this to your path:
export PATH="/usr/local/opt/python/libexec/bin:$PATH"
Read the Caveats section in 'brew info python':
==> Caveats
This formula installs a python2 executable to /usr/local/bin.
If you wish to have this formula's python executable in your PATH then add
the following to ~/.bash_profile:
export PATH="/usr/local/opt/python/libexec/bin:$PATH"
Pip and setuptools have been installed. To update them
pip2 install --upgrade pip setuptools
You can install Python packages with
pip2 install <package>
They will install into the site-package directory
/usr/local/lib/python2.7/site-packages
See: https://docs.brew.sh/Homebrew-and-Python.html
In order to install a python distributions into specific folder, you can use the --prefix scheme during python installation. Using the prefix scheme, you can for example install Python 2.7 into the folder /opt/py27. Now, in order to use the new installed Python distribution you have to: cleanup you PATH and LD_LIBRARY_PATH:
Remove all 'old' Python paths and
configure (according to my example) the environment variables like this:
PATH: Add /opt/py27/bin
LD_LIBRARY_PATH: Add /opt/py27/lib
That's it.
(In case you need multiple environments of Python installed at the same time, I'd suggest to have a look at virtualenv)
tl;dr
brew install python
Symptoms
I had similar issues with python programs not finding dependencies.
My python3 version was a broken symlink.
My pip was pointing to a python 3.8
And my pip3 was pointing to 3.9
python -V was outputting some python 2.7 version
python3 -V was outputting some python3.8 version
Solution
I ran brew install python and it fixed all my problems.
How do I install and run Python 3.8.1 on Linux? Python.org does not offer a Linux binary for Python 3.8.1.
I want to type:
dnf -y install python or dnf -y install python38
and have it install Python 3.8.1 on my RHEL 8.0 or 8.1 inside my minimal container that I want to keep small.
How would I make this happen?
I don't even see a download for Python for Linux on python.org.
Do people use Python on Linux?
There are no Linux binaries to be downloaded from Python.org
I have searched all over (internet search), and cannot find a way to install Python 3.8.1 easily on a minimal container.
I do not want to download the source and compile, because it is a small container that I am trying to keep small without a lot of overhead.
Reference:
https://www.python.org/downloads/release/python-381/
Two notes: I'm not sure how your container is set. You've tagged this as both RHEL and Fedora. These are two separate distributions. I can comment on Fedora.
Firstly, yes, Python is heavily used in the GNU/Linux world. Most distros use it as one of the languages to build the system and its packages. Linux servers are the only officially recommended servers for Python, or so I've read (will edit with source later if I can find it). Python.org does have Linux downloads, but in source files, packaged in compressed tarballs. This can promote searching the distro package manager first for distro compatibility (since being in a distro's repo should mean the version was vetted); these packages are precompiled unless otherwise specified. It also means the files are distro agnostic -- no need for .DEB, .RPM...
Fedora: There isn't a Fedora version listed in the post, but at least Fedora 31 has a development version, as they call it, of Python 3.8.1 in RPM format. (Fedora 32 is slated to have Python 3.8 at the system level.) You can get it with:
sudo dnf install python38
Be sure not to overwrite the system variables for python or python3; this mistake can cause systemic issues of varying magnitude. Once installed, you can create a virtual environment in whichever directory you'd like with:
python3.8 -m venv <venv_name>
To activate the venv, use:
. <path/to/venv>/<venv_name>/bin/activate
You can set an alias or symlink for ease. When the venv is activated, Python 3.8.x will be the Python version used when the interpreter is called. You should see your venv_name in parentheses, to the left of your PS1. To deactivate, use:
deactivate
The venv_name should be removed from the PS1, returning it to normal. Checking the Python version should return the system-level Python version.
If you check your Python version before and after the activation, it should be different.
python3 -V
This package may or may not have been sent downstream to RHEL. If you have the package available but want the full Python stack, or if it isn't available in RHEL's baseline repos, you may need to grab the source files and unpack the tarballs.
Alternatives are checking other repos, seeing about RPMs that someone else compiled from source, or checking out flatpak (which I haven't done).
Last note: compiling from source shouldn't result in a larger Python binary. You can delete any unnecessary extras, like the original archive file used for compiling, after you've extracted what you need. The action itself will only be stored in volatile memory, not on your disk.
During the past years, I have installed many Python libraries with various Python versions. To make them ready to work immediately, I installed them blindly without control. Currently they're causing problems when I tried to install pynest which invokes numpy, scipy and matplotlib. After struggling, I am going to clean and reinstall Python and the libraries.
After investigation, I found Python 2.5/2.6/2.7/3.2 on my system, and each of them has some copies or other things at: (my OS == Mac OS X 10.7.5 Lion)
/Library/Frameworks/
/opt/local/Library/Frameworks/
/opt/local/bin/
/Applications/
/usr/local/bin/
/usr/bin/
/System/Library/Frameworks/
I know I'm crazy to have these. Now I have removed all these except the things in /System/Libarary/Frameworks (I never remove any thing from /System/Library/). After the clean work, which python now gives /usr/bin/python which links to /System/Library/Frameworks.
Now, is it a clear environment for me to reinstall python? How to double check that there's no other versions existing? How should I reinstall them to guarantee that they and their libraries won't be everywhere and have many copies again?
I want to install a clean Python 2.7 onto a proper location, and make my system know exactly where it is and never install any libraries somewhere else. Please give me some advice that how to manage it like in a professional way.
For your information, here is my current $PATH, I think it should be modified:
/opt/local/bin:/opt/local/sbin:/opt/nest/lib/python2.7/site-packages:/usr/local/lib/python2.7/site-packages:/Library/Frameworks/Python.framework/Versions/2.7/bin:/usr/texbin:/Library/Frameworks/Python.framework/Versions/3.2/bin:/usr/bin:/bin:/usr/sbin:/sbin:/usr/local/bin:/usr/texbin:/Library/Frameworks/Python.framework/Versions/3.2/lib/python3.2/site-packages/django/bin:/usr/X11/bin:/opt/local/bin:/opt/local/sbin:/usr/local/lib/python2.7/site-packages:/Library/Frameworks/Python.framework/Versions/2.7/bin:/Library/Frameworks/Python.framework/Versions/3.2/bin
Please let me know If you need more information. Thank you!
UPDATE:
I'm rethinking profoudly why it becomes so crazy. I believe it's because I installed things via:
easy_install / macports / homebrew / fink / pip sometimes;
.dmg sometimes;
.pkg sometimes;
compile source code sometimes;
and they made things at different locations. I wonder what's the mechanism behind these ways? How do they choose target location? How to prevent them from messing things up?
Why did it get messed up?
There're a couples of different way to install Python, as the update of OP says, and they locate files in different locations. For example, macports puts things into /opt/local/, while homebrew puts things into /usr/local/. Also, Mac OS X brings a few python versions with itself. So, if you install python many times via different ways, you will get many python versions existing independently on your system.
What problem does it cause?
I don't know exactly. I guess the problem is that if you have many versions of python, then which one to use and where to find packages will be determined by the path order in your system PATH and the PYTHONPATH respectively. So you may lose control of where to install python modules. Consider that if you run sudo python setup.py install to install a module (it finds python by the root's PATH) and then try to import the module by python -c "import it" (this time it finds python by your PATH), maybe something will go wrong. This is my guess, I didn't validate it. But in my own case, something did go wrong.
How to avoid this?
I think the principle would be that be aware of that different ways and tools install things independently to different locations, so use them mindfully.
Unless you intend to, don't install the same thing twice via different
ways. (If you intend to do it for python, you might want to check out virtualenv)
Keep an eye on the path order in your PATH and consider if it's
correct.
When installing modules, be clear which python (or pip) is
running and where the module is installed.
So, how did I solve my own case?
Since it had been messing up already and seemed to be very hard to cure, so finally I solved this question by a full OS re-installation, and started to follow the DOs-and-DONTs above. For the installation of the scientific environment with python (numpy/scipy/matplotlib, which had shown problems to make me ask this question), I found this tutorial was extremely helpful. So, problem solved finally.
Here is what was confusing me and how I solved it.
$ which python
/usr/bin/python
$ which python3
/usr/local/bin/python3
$ ls /usr/local/bin/python
ls: /usr/local/bin/python: No such file or directory
So notice I didn't have a HomeBrew installation of python2.7, but did have the python3 installation. The version under /usr/bin/python is using the system default. You can tell based on the module search path:
$ /usr/bin/python
Python 2.7.10 (default, Feb 7 2017, 00:08:15)
[GCC 4.2.1 Compatible Apple LLVM 8.0.0 (clang-800.0.34)] on darwin
`enter code here`Type "help", "copyright", "credits" or "license" for
more information.
>>> import sys
>>> sys.path
['', '/Library/Python/2.7/...
Notice the '/Library/Python'... that's Mac OS's version of python. But I want to stay strictly on a user installed version (i.e. HomeBrew).
So here's what I did to fix this:
$ brew install python
...
Warning: python 2.7.13 is already installed, it's just not linked.
You can use `brew link python` to link this version.
$ brew link --overwrite python
$ which python
/usr/local/bin/python
$ python
Python 2.7.10 (default, Feb 7 2017, 00:08:15)
[GCC 4.2.1 Compatible Apple LLVM 8.0.0 (clang-800.0.34)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> import sys
>>> sys.path
['', '/usr/local/Cellar/python/2.7.13...
Its no longer /Library/.. but /usr/local.
Now its finding all of my pip installed modules! Problem solved!
UPDATE:
After updating brew to version 1.5.4, it seems the symbolic links were removed. And now you have to add this to your path:
export PATH="/usr/local/opt/python/libexec/bin:$PATH"
Read the Caveats section in 'brew info python':
==> Caveats
This formula installs a python2 executable to /usr/local/bin.
If you wish to have this formula's python executable in your PATH then add
the following to ~/.bash_profile:
export PATH="/usr/local/opt/python/libexec/bin:$PATH"
Pip and setuptools have been installed. To update them
pip2 install --upgrade pip setuptools
You can install Python packages with
pip2 install <package>
They will install into the site-package directory
/usr/local/lib/python2.7/site-packages
See: https://docs.brew.sh/Homebrew-and-Python.html
In order to install a python distributions into specific folder, you can use the --prefix scheme during python installation. Using the prefix scheme, you can for example install Python 2.7 into the folder /opt/py27. Now, in order to use the new installed Python distribution you have to: cleanup you PATH and LD_LIBRARY_PATH:
Remove all 'old' Python paths and
configure (according to my example) the environment variables like this:
PATH: Add /opt/py27/bin
LD_LIBRARY_PATH: Add /opt/py27/lib
That's it.
(In case you need multiple environments of Python installed at the same time, I'd suggest to have a look at virtualenv)
tl;dr
brew install python
Symptoms
I had similar issues with python programs not finding dependencies.
My python3 version was a broken symlink.
My pip was pointing to a python 3.8
And my pip3 was pointing to 3.9
python -V was outputting some python 2.7 version
python3 -V was outputting some python3.8 version
Solution
I ran brew install python and it fixed all my problems.
I am currently running RHEL 6.6. This has python 2.6.6 pre-installed and is the default. I installed python 2.7 using the altinstall method. The default python is still 2.6.6. I'm trying to install the python-devel packages using yum which only runs with root. However when I run yum install python-devel as root it installs the packages to python 2.6.6.
Is there a way to get yum to install packages using the alt python install?
You may want to use the Python 2.7 version that is available as part of "Software Collections". This is installed along side the original 2.6 and doesn't try to replace it (and is included in nearly all RHEL subscriptions.) See info here:
Introduction: http://developers.redhat.com/products/softwarecollections/overview/
List of available components including Python 2.7: https://access.redhat.com/documentation/en-US/Red_Hat_Software_Collections/2/html/2.0_Release_Notes/chap-RHSCL.html#sect-RHSCL-Features
It's still a yum install, but with an extra command or two. You can start with this Get Started guide for Python 3.4 (http://developers.redhat.com/products/softwarecollections/get-started-rhel6-python/) but swap out the Python versions in steps 2 and 3.
I'm running Mint 9 and I can't get Virtualenv to run. Every time I run it I get an ImportError for zlib, while the Software Manager claims both zlib1g-dev and zlib1g are installed.
One interesting thing is that there's no PYTHONPATH environment variable set. Is this typical and could it be the problem why zlib can't be found?
Edit:
I also did confirm that it really wasn't available from a standard Python prompt. How do I ensure libraries are available within Python?
Edit:
Ok I found the problem, I was trying to use Python 2.7 and the default for the distro is 2.6. The zlib libraries seem to only be installed into Python 2.6. How do I get them into 2.7 also?
virtualenv doesn't export a PYTHONPATH, instead VIRTUAL_ENV is exported, then the sys.path thing is handled by site module.
The zlib is in the standard library, and it's configured to be enabled by default, so I guess you didn't have zlib-dev installed.
try:
sudo apt-get install zlib1g-dev
and recompile yr python2.7.