I have installed some modules using pip and whenever I try to import them in Python I am told that no module exists. I think there is something wrong with my paths. This is some terminal output, does anyone know how I can fix this?
Nicks-MacBook-Pro:~ nickporter$ which python
/usr/bin/python
Nicks-MacBook-Pro:~ nickporter$ which pip
/usr/local/bin/pip
Nicks-MacBook-Pro:~ nickporter$
You can use pip freeze to find the packages installed.
I do not know whether you use a virtualenv. If you use it, you have to source it, to activate it.
It looks like you probably have multiple installations of Python or pip (or both). First, determine if you have multiple Python binaries installed and decide on the one you want to use by default.
You clearly have /usr/bin/python...check if there is another one in /usr/local/bin/python. If you do have one in /usr/local/bin, I'm guessing you installed it with Homebrew. Pick the Python you want to use (if there are multiple) by playing with your PATH. If you want to use /usr/local/bin/python (assuming it exists) ensure /usr/local/bin comes before /usr/bin in your PATH.
Once you do that, I would remove your current pip. After you remove it, look for it again with which pip, just to make sure you don't have any old one laying around. Once you've totally removed it, reinstall.
If you're installing with Homebrew, I'd stick to using the Homebrew python and pip. If you're not using Homebrew I'd install pip using: https://bootstrap.pypa.io/get-pip.py
curl -q https://bootstrap.pypa.io/get-pip.py | sudo python
You have homebrew version of python shadowed by the system python, but because system python doesn't have pip, a pip you see is actually a brew one.
I found, that the reason for this is that brew by default names python2.7 as python2 in /usr/local/bin (probably for preventing possible compatibility issues with some system services (?)) , i.e. you may try to run python2 or try to ln /usr/local/bin/python2 /usr/local/bin/python and restart the term session.
Make sure that /usr/local/bin goes before /usr/bin and /bin in your $PATH.
BTW. brew info {package} often contains recommendations for proper configuration of packages.
Related
After upgrading my system interpreter to python#3.8 with brew, now everything got out of order. I think brew had symlinks of pip3 through pip which enabled the direct use of pip install <package> instead of using pip3 after the upgrade, this thing stopped existing, whenever I call pip, I get a bad interpreter: No such file or directory <python3.7 old directory> and I wasn't able to install any new packages unless I refer to pip3.8 by full path which is in /usr/local/Cellar/python#3.8. So I symlinked pip to pip3.8 which is not the best practice ever, and most packages depend on python3.7 are currently crashing ex: jupyter notebook, which when I start using jupyter notebook from the terminal, it opens jupyter in the browser, but as soon as I open a notebook, I get a kernel error because for some reason it depends on python3.7 which is not there. Even when I tried python3.8 -m jupyter notebook I get the same error. Needless to mention most of the packages that are launched from the terminal ex: scrapy are looking for python3.7 interpreter. So I installed python#3.7 using brew which is automatically not installed in /usr/local/bin or /usr/bin to avoid clashing with the system.
So ... you got the idea, I have a mess and as I do not understand the dynamics of how python structure lives within OSX system I was thinking the best way is wipe all python3.x including packages, pip and various components, break dependencies and let them depend on native python2.7 maybe or I don't know I'm sure there is some clean way to do it and then do a clean install of python3.8. Any suggestions on how to do this without creating more mess and be able to clean everything up and do that clean python3.8 install at the end?
You might try using which python or which python3.8 to be able to find where they are and remove em if that's what you want to do.
You can also try alias python=python3.8 or whatever version you end up needing. To make it so you don't have to type that every time you open a new terminal, you can edit ~/.bashrc and add it in there that way it's the default.
As Python 3.7 was being prepared I installed Python 3.7.0b3 from source. Now 3.7 is out and I want to use the version packaged for Ubuntu. So I've done
apt-get install python3.7
but
$ which python3.7
/usr/local/bin/python3.7
$ /usr/local/bin/python3.7 --version
Python 3.7.0b3
How does one uninstall a Python installed from source (on Ubuntu)?
Or how can I replace it with the apt repo packaged version?
Since you opened a bounty, I can't vote to close as a duplicate, but this question would seem to provide a possible solution. Quoting from the accepted answer:
You can use checkinstall to remove Python. The idea is:
Install checkinstall
Use
checkinstall to make a deb of your
Python installation
Use dpkg -r to
remove the deb.
checkinstall basically wraps a make install command and creates a Debian .deb package based on what was installed. Then, you can just uninstall that package to reverse make install completely. To be perfectly safe you may want to uninstall the packaged Python 3.7 first and reinstall it afterwards to avoid any conflicts (I wouldn't expect any, though, since the packaged version lives in /usr while your source version lives in /usr/local).
If you don't have your source files around anymore, you can always download them again (https://www.python.org/downloads/release/python-370b3/) and rebuild Python. Specifically, the checkinstall commands would look something like this:
sudo apt install checkinstall
wget https://www.python.org/ftp/python/3.7.0/Python-3.7.0b3.tgz
tar xf Python-3.7.0b3.tgz
cd Python-3.7.0b3
./configure && make
sudo checkinstall -D --fstrans=no make install
sudo dpkg -r Python-3.7.0b3.deb
(-D creates a Debian package, --fstrans=no disables use of a temporary directory for installation).
Since I was also moving to python 3.7, I came across this question and decided to answer it, as well as finish my installation.
This are the two sources, which I used for installing python 3.7 on ubuntu 16.04:
https://askubuntu.com/questions/865554/how-do-i-install-python-3-6-using-apt-get
https://superuser.com/questions/241865/updating-python-on-ubuntu-system
Apparently from the first source the deadsnakes PPA contain Python 3.7 - Link: https://github.com/deadsnakes/python3.7/tree/ubuntu/xenial/Python
So following from my first source, I used the following commands to install Python 3.7:
sudo add-apt-repository ppa:deadsnakes/ppa
sudo apt-get update
sudo apt-get install python3.7
It installed Python 3.7 successfully but my Python 3.5.2 remains default. You can invoke/use Python 3.7 by running the commands:
python3.7 script.py
It works, so I decided to set Python 3.7 as default by removing python 3.5, but I came across my second source, and just decided to stick with using python3.7, when running my script in the terminal.
Apparently it says:
Ubuntu policies extensively for writing end-user software. So basically, a large part of the system is written in Python. To switch to Python 3.7, there needs to be done a piece of work consisting of updating and re-testing all the scripts.
So to say you can't just switch to Python 3.7 and delete the older version.
Also from a comment from my first source it states deleting the older version might break the system. I haven't been around to deleting my older version in case it might break the system, but since you are asking for how to download Python 3.7, I think my first source and the first part of my answer should to the work.
I hope it helps :)
It seems that your Python built from source is under /usr/local, and your PATH variable has /usr/local/bin before /usr/bin, since running python3.7 gets you the one under /usr/local rather than the packaged one which would be /usr/bin/python3.7.
Look at your PATH to verify this.
echo $PATH
(When you run a program in bash, that particular running bash instance will remember the location and not rescan the directories in the PATH for that program again, so it will not notice a new file that has appeared somewhere earlier in the PATH. You can prevent this by running hash -r to reset the cache or by just exiting the shell and launching it again.)
I presume your goal is for python3.7 (or any of the other commands provided by Python) to run the versions from your packaged install in /usr.
Unfortunately the python build process does not provide an uninstall method -- the only automated way to remove just the files installed by a source Python install requires using other tools ahead of time (such as checkinstall).
So you have some choices :
Change your PATH so that /usr/local/bin is after /usr/bin. To do this, edit your ~/.profile file or whatever other script you have configuring your PATH and logout/login. This will also affect any other commands you run that are available in both /usr/local/bin and /usr/bin.
Remove /usr/local and reinstall anything else you want there. If a Python install is the only thing in your /usr/local, or if you can easily reinstall anything else you had there, this might be the way to go.
Painstakingly figure out what files under /usr/local/bin were part of Python and remove them. You might be able use the corresponding files in /usr/bin from your installed python3 packages as a starting point to figure out the similar names for /usr/local/bin.
One-liner to get the list of files in /usr/bin from installed python3* packages:
$ for pkg in $(dpkg -l 'python3*' | grep '^ii' | cut -f 3 -d' '); do dpkg -L $pkg | grep '^/usr/bin/'; done | sort
This should produce a list of files like:
/usr/bin/2to3-3.x
/usr/bin/chardet3
...
(I've tested this one-liner on Debian, I'm not sure if any changes are required for Ubuntu)
I have upraded my Linux distro recently. Python 3.5 was replaced by Python 3.6.
All site packages I have installed with pip3 are still in the /usr/lib/python3.5/site-packages directory and Python does not find them there now, because it looks in .../python3.6/site-packages obviously.
I see the directory contents and I could manually install them again, but that does not look to me like the right way to do it. I could move the contents to the new directory, but again, this seems to me incorrect either.
How am I supposed to handle it properly?
Should I have prepared a pip3 freeze list before the upgrade?
I tried to search, but the keywords are probably too general and got many unrelated answers.
Python 3.5 was replaced by Python 3.6. But you still have the backup option of using python 3.5.
If you want to use python 3.6 you will have to reinstall all pip packages again for python 3.6. And it makes sense.
Say you were changing from 2.7 to 3.5. You would want to preserve both the environments separately. Hence 3.6 environment is different from 3.5.
A quick way to do this would be to pip freeze for 3.5 and then install those dependencies for 3.6.
pip freeze > reqs.txt
upgrade
pip install -r reqs.txt
Since you don't have this option anymore, first try and list all packages in your python3.5
for that you can install pip3.5 as answered by #kabanus.
sudo apt-get install python3=3.5.1*
sudo python3.5 easy_install.py pip
Also it's advised to use virtual environment per project so you can maintain separate environments for each of them.
I just hit the same problem upgrading from Python 3.6 to Python 3.7, I forgot to run pip freeze before I upgraded to Python 3.7. The solution that worked is to specify the --path option as the old site-packages/ directory (which was not deleted):
pip3 freeze --path /usr/local/lib/python3.6/site-packages/ > python3.6_requirements.txt
pip3 install -r python3.6_requirements.txt
This would have made things simpler for you to reinstall. Checkout the description. Using freeze you could have done something like:
$ env1/bin/pip3 freeze > requirements.txt
$ env2/bin/pip3 install -r requirements.txt
Generally the recommended method is you use a virtualenv for site packages, so you don't litter your installation areas, but TBH it never broke something for me. Another option is to check if the linux distribution has the package available for proper retrieval, as in:
sudo apt-get install python3-<somemodule>
This is what I prefer - and could have been upgraded with the distro. As for what to do now, If you really don't want to re-install everything properly you could try to cp /usr/lib/python3.5/site-packages/* /usr/lib/python3.6/site-packages. The differences between versions are not so great such that I believe most packages would work off the bat. You may have to sed to replace python3.5 with python3.6 in all files there though. Forgot delete all pyc files if you do this.
Python modules are self contained enough that if something is broken it can be handled per package, and the site packages are self contained completely, so you could always just remove everything and re-install.
A final note - you can try and install pyton3.5/pip3.5 for your linux, and then do the freeze thing. If there is no package you could install manually (whl or such) or compile a stand alone and configure the site path properly. If you want to keep things on a global site package directory or migrate to virtualenv this may be the safest option.
I need to work with Both Python 2.7.12 and python 3.5.2 simultaneously on my Ubuntu 16.04.1 LTS. Python 3 came pre-installed so I've no idea where it sits, in terms of path to the directory, while python 2 sits in /usr/local/lib/python2.7/.
I found lots of questions on SO and on askubuntu about how to install but nothing about how to use them separately, installing different libraries, and what should I avoid or be careful of, if I maintain this dual python thing for the long term? For example, I usually run pip install to install a library and I can check that its installed in my python2 directory but how do I install the same package for my python3 without conflicts? Something like: python3 pip install <package> ?? Where is the default python3 installed? And how do I call python3 for paths where python is not part of the command for example: pip freeze, sudo-apt get, etc.?
PS: I've not officially worked with Virtualenv but I've been informed that is usually good for isolating projects within a python language version, rather than isolating two different language versions from each other.
Please let me know.
Thanks
This is absolutely no problem, as Python does that for you. You don't need a virtualenv at all.
If you use Ubuntu packages, make sure you use the python3- versions for Python 3, and the normal python- versions for Python 2.
For example, python3-numpy and python-numpy.
If you use pip to install extra packages, you an either use the pip script with the version number appended: pip2.7 or pip3.5, or, my preferred method, call pip as a module for the respective Python executable:
python2.7 -m pip install <whatever>
and
python3.5 -m pip install <whatever>
Other than that, there should not be any issue: Python stores the packages in completely separate directories, and each Python executable only uses its respective directive.
Do not fiddle around with PYTHONPATH, unless you really know what you're doing. This has the danger of setting your PYTHONPATH to a directory with Python 2.7 modules and then using Python 3.5 to run things.
If you start from scratch, you may need to install pip first.
For the system Python(s), use the relevant package:
sudo apt install python-pip
sudo apt install python3-pip
For your locally installed Python(s), use the built-in bootstrapper module:
pythonx.y -m ensurepip
Note on the OS-installed Python executables:
Python 3.5 lives at /usr/bin/python3.5, Python 2.7 (the OS one) at /usr/bin/python2.7.
You could even use the OS 2.7 one next to your locally installed /usr/local/bin/python2.7 (and confuse yourself when a package can't be found because you used the wrong one).
Or install Python 3.6 next to Python 3.5 (provided you've used make altinstall, so python3 doesn't get overwritten).
This is also why you don't really want to run pip (or even pip2.7) as is: pip2.7 may get you the system one, instead of the one in /usr/local/bin/pip2.7, depending on your PATH.
(The same goes for the python2.7 executable, so if you need to specify the full path /usr/local/bin/python2.7 to run that one (or have an alias), the same holds for pip2.7. If, on the other hand, /usr/local/bin is first on your PATH, you should in principle never run into the same pip and python executables.)
I went thought and installed pip and then added a bunch of libraries that I like to use and then, only after installing everything, did I realize that everything went into the 2.7.2 sit-packages directory, so the Python2.7.5 version doesn't see anything.
Now, If I type python --version in the terminal, the correct version is started. However, pip is still "tied" to the default version of Python.
How do I go about telling OSX to look at the new version of Python for everything?
Honestly, one way around this is to make sure that virtualenv works with the right version, and just use pip inside the virtualenv.
A common pattern of Python installation on the mac is to use Home Brew which is a package manager for the mac. You can then install python using:
sudo brew update
brew install python
Provided you have the XCode command line tools already installed.
After I think that the Home Brew Python will be the first in the path. If this is not the case, it might be simpler to use a virtualenv by installing the package with the pip provided by the Mac Brew install (/usr/local/Cellar/python/2.7.5/bin/pip).
After this is done you need to create a virtualenv
virtualenv ~/path/to/the/env
and to activate it
source ~/path/to/the/env/bin/activate
This will be a brand new python and your path will be configured correctly (the python and the pip will be the right ones). You can always delete it, deactivate it or source it as needed.