This question already has answers here:
Modules between multiple versions of Python Linux
(2 answers)
Closed 8 years ago.
I have 2 versions of python 2.7 and 3.3. I installed virtualenv hoping that I can work using two different python version.
I created my first project environment:
/usr/local/bin/virtualenv -p /usr/local/bin/python2.7 first
and installed pymysql package which is available to that environment only.
Now I want the same package to be available globally - how can I do that?
When I run pip install without setting the environment it actually installs in 3.3 version site packages which eventually fails as it is compatible for 2.7?
To have packages available globally you must install them globally. virtualenv is made specifically for making separate package installations. It doesn't provide anything else so I have no idea why are you using it.
You don't need to use virtualenv to have two Python version installed. In fact, virtualenv doesn't help with that at all. Virtualenv is to install several installs of the same Python version.
So to have two different versions of Python installed you simply just install two different versions of Python. It's that simple.
http://regebro.wordpress.com/2011/02/02/newbie-hint-on-installing-python-and-its-modules-and-packages/
Related
This question already has answers here:
How to run pip from different versions of python using the python command?
(4 answers)
Closed 4 years ago.
I have installed Python 3.7 I can use Python 3.7 by typing python3 command in terminal.
However if i type pip --version or pip3 --version it prints pip 18.1 from /usr/local/lib/python3.5/dist-packages/pip (python 3.5) in either case. So i cannot install packages to use with Python3.7
How can i set pip3 path and Python version to use it with Python3.7 ?
BTW i use Raspbian Stretch as OS.
Your path is probably not properly configured.
In general, it's best to leave system Python version untouched to avoid breaking things.
I would recommend using pyenv to manage and easily switch Python versions. It can easily work with virtual environments as well, or even as a substitute.
Install from here: https://github.com/pyenv/pyenv#installation
Python newbie here. I just bought a new Mac Book Pro (switched from Windows) and Python 2.7 is already installed on it. I want to install 3.6 side by side and choose between the two versions. I found a great tutorial located here http://joebergantine.com/articles/installing-python-2-and-python-3-alongside-each-ot/ but I'm confused on one of the command line operations. Under Python 2 Installation it says:
Install Python 2 from the latest Python.org package. This allows you to run python2 and pip. After this installation Python 2.x will be accessible at /Library/Frameworks/Python.framework/Versions/2.7/bin/.
Once the Python 2 package is installed, install virtualenv for Python
2 for the User only. When specifying the User installation, Python
packages are then accessible at ~/Library/Python/2.7/bin. Specifying
the User installation doesn't automatically add virtualenv to the
system path which we will do manually in the next step via an alias.
This is what allows Python3 and Python2 to run alongside each other:
$ pip install --user virtualenv
Do I have to be in the ~/Library/Python/2.7/bin directory when I run this command or the /Library/Frameworks/Python.framework/Versions/2.7/bin/ directory? I'm confused because I don't know where the former directory is coming from.
Why not using pip for python 2.7 and pip3 for python 3.6?
If it says pip3 is not installed you can use sudo apt-get install pip3
then you can use pip3 for python 3.6 and pip for python2.7 for installing packages for respective versions
I faced the exact error, in the exact situation about 2 years ago. The solution to your issue is pyenv. I was able to run multiple versions of python inside different folders of the same directory. It truly was a very nice solution.
Hope this helps.
In the usr/bin folder, there are three versions of Pythons installed: Python, Python2.6, Python2.7 (the folder names) - not sure what version is for Python folder.
My issue, originally, was that I tried to install the module 'pandas' to run a script, python keeps telling me pandas could not be found.
'pip freeze' shows me pandas is already installed.
However, I could not find pandas using python>>help>>modules.
So I suspected there are multiple pythons installed causing pip installing for one of them, but the default python is a different one.
So my questions are -
1 Which python is the default one that comes with macOS Sierra? (I can confirm pandas currently is installed for Python, not Python2.6 or Python2.7)
2 Can I remove extra Pythons that do not have pandas?
3 How can I find what it the default Python when I type 'Python...' and how to install pandas for that python?
Solved:
Thanks for the comments and reply.
I used "python2.7 install pip" to install pip for python2.7. Then I used command 'pip2.7 install pandas'. This way, pandas is installed for the default python. (The command 'pip install pandas' on my machine, is installing for python 2.6.)
macOS Sierra uses Python 2.7 by default.
You can uninstall a version of Python as described here. However, you shouldn't need to as long as you are managing your packages and environments. If you want to maintain more control over your projects and their packages/versions, you should take a look at virtualenv. Virtualenv creates environments that have their own installation directories that don't share packages with other virtualenv environments. This is a very popular option many people use when managing projects.
You can use pip --version to see which version of Python you are installing a package for. You can also use pip list to see which packages are currently installed.
I highly recommend taking a look at virtualenv as it'll make keeping track of Python environments and their respective packages a lot easier.
Hope this helps!
I don't know what I have did but now when use pip to install a package it install it for python 3 (python3.3 folder) not for python2.7.
Another problem I installed django_debug_toolbar and now my django version is 1.6.4 not 1.3 I installed.
Now I can't remove django 1.6.4 with pip. Do you have a solution?
Learn using virtualenv. It allows you to have different environments with isolated version of Python and set of installed packages. Each created virtual environment is by default having pip installed.
You messed up things (as you know very well) as you probably reinstalled pip for another version of Python.
You might find more versions of pip in your system. Check the version of python they use (on Linux watch the shebang on first line). Use explicit path to proper pip to manage packages for related Python.
Often people install pip and rename it or give an alias - names like pip33 or pip27.
Note, that virtualenv allows creation of different environments (with different Python versions) without need to install virutalenv for each of these Pythons.
With virtualenv I would also highly recommend using virtualenvwrapper which adds a few very handy commands.
My problem came when I installed django_debug_toolbar. when I pip-installed django-debug-toolbar, the latest version of Django was installed automatically.
This question already has answers here:
Why does pip freeze report some packages in a fresh virtualenv created with --no-site-packages?
(2 answers)
Closed 9 years ago.
I am using virtualenv version 1.7.1.2 with python 2.7.3 to create virtual python ennvironments. But when I create such an environment and activate it, I can see the following packages are installed (using pip freeze):
argparse==1.2.1
distribute==0.6.24
wsgiref==0.1.2
Why is that? What does that mean?
These are the standard packages, and will always follow with that version of Python and Virtualenv.
distribute is pretty self-explainatory. It's necessary for pip. Distribute also contains setuptools, but inside the package so not recognized with pip freeze. For more information about what it actually does check out your env/lib/python2.7/site-packages/distribute-0.6.31-py2.7.egg.
wsgiref is actually a part of the standard library, but isn't recognized as so. There's a bug report on it, and it's fixed in Python 3.3+. Read more about it in Why does pip freeze report some packages in a fresh virtualenv created with --no-site-packages?
I can't find out why argparse is there though, but my guess is because it's a dependency or something like wsgiref. Finding package dependencies in Python can be a bit hacky/painful though, especially if it's already installed in your virtualenv.