We Keep Coding

Remove newer version of python using Homebrew, keeping an older version OR using site-packages in newer version

I have used python 3.8.13 as installed by Homebrew for years, mostly with jupyter-lab for coding in notebooks. Recently I ran brew to install a package and it looks like it installed python 3.10: brew list shows both python#3.8 and python#3.10 and running python3 from the command line gives me a 3.10 session, with no knowledge of my site-packages...
I either want to:
remove python 3.10 and continue using 3.8 as I was. python#3.8 would then be the python3 command as it was before.
or
change over to using python 3.10 and have all the site-packages installed when using 3.8 "come with". In particular, jupyter-lab needs to know about them in the 3.10 environment so my notebooks keep working.
Could someone help me with either of these? I'm not familiar enough with brew or python to clearly see how to do either to completion. Thanks so much.

How to install brownie on mac os running both python 2.7 and 3.9 [duplicate]

I am trying to get python 3 working on my OSX laptop.
I need to install requests for python 3, and it isn't working.
I think I've managed to get pip installed for both python 2.7 & python 3 however...
Whenever I use 'pip' it points to python2... I can't seem to access the pip for python 3?

In all likelihood, pip3 will be installed pointing to your Python 3 installation, so your use case is probably solvable by just switching from:
$ pip install foo
to:
$ pip3 install foo # Or pip3.7 install foo if you need to disambiguate further
That said, it can get kind of complicated when you have many different Python installs, where pip/pip3 might have been installed pointing to a Python version that doesn't correspond to the python/python3 you're using, which can be quite confusing.
If you know python & python3 are the correct executable, just use it to invoke pip on your behalf. It's fairly easy too, just check your version to be sure it's the one you expect (e.g. on my system):
$ python --version
Python 2.7.15rc1
$ python3 --version
Python 3.6.6
then use the appropriate one with -mpip, a flag to run an installed module/package via the chosen Python as the "main" executable, bypassing the need for specifically versioned pip executable entirely. So if you wanted to install foo for Python 3.6 on my machine, you'd run:
$ python3 -mpip install foo
This is especially useful on Windows, where the pip executables often either don't exist, or are not installed in the PATH, so it's irritating to use them. Instead, use the Windows launcher that comes with any modern Python 3 version (but manages all Python versions on the machine), and is used to disambiguate among various versions. For example:
C:\>; Installs foo for latest installed version of Python 3
C:\>py -3 -mpip install foo
C:\>; Installs foo for latest installed version of Python 2
C:\>py -2 -mpip install foo
C:\>; Installs foo for latest installed version of Python 3.6
C:\>py -3.6 -mpip install foo
Essentially, any use of pip can be replaced by executing the Python interpreter directly with the -mpip option to run the pip package as the "main" executable.
This trick applies to many other tools with dedicated launchers that are often not installed in the PATH, particularly on Windows, and it makes updates easier too; my Windows shortcut for launching ipython3 never used a hardcoded path to the launcher (e.g. C:\Program Files\Python36\Scripts\ipython3.exe), instead using %WINDIR%\py.exe -3 -mIPython. In addition to being more portable (the shortcut "just works" on any Windows system with a semi-recent Python 3 install), it's self-updating; when I upgraded from 3.6 to 3.7, the shortcut didn't have to change at all (I had to run py -3 -mpip install ipython again to get IPython reinstalled, but once I'd done that, the shortcut seamlessly began referring to the 3.7 install with no changes needed).

Run this command to find the python that is used before running pip: which python. You can do the same idea to find which pip version is being run: which pip
You’ll need to create separate virtual environments in order to use different python versions and/or python dependencies. Use something like conda or venv to do this. Then, ensure that the desired python version virtual environment is activated prior to installing a new package with pip.

To install requests for python3, use pip3 install requests which is the pip installer for Python 3 modules.
This guide has some further info on getting Python 3 working on a mac.
https://docs.python-guide.org/starting/install3/osx/

try to sudo apt-get update first then sudo apt-get install python3-pip --fix-missing

Installing Python 2.7 and 3.6 Side by Side on Mac

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.

Coexistence of Homebrew and pyenv on MacOSX Yosemite

Several newbie questions about coexistence of Homebrew and pyenv on MacOSX Yosemite. These are the things that I am still confused about after applying my level of google-fu to the subject. Sorry for the length, but I wanted to be as clear as possible.
First, some background. I used brew to install pyenv, then pyenv to install python2 and python3.
brew install pyenv
brew install pyenv-virtualenv
*I also added the necessary hooks into my profiles.*
pyenv install 2.7.10
pyenv install 3.4.3
pyenv rehash
pyenv global 2.7.10
??? Question (or clarification). If brew is using a python installed by pyenv, I assume that this is frowned on because brewed packages would be built with a dependency on something outside of brew (e.g. using pyenv to uninstall a python version could break brewed packages)? It appears that brew uses whichever python comes first in the PATH (currently pyenv's version for me)? However, in each of the below cases the shims are for “python” rather than “python3” (even for pyenv 3.4.3). Am I correct then in assuming that setting “pyenv shell 3.4.3” will make brew link python commands (that it assumes are for python2.x) to pyenv’s python 3.4.3, which I guess would tend to mess things up?
pyenv shell 2.7.10
brew --config
Python: /Users/anonymous/.pyenv/shims/python => /Users/anonymous/.pyenv/versions/2.7.10/bin/python2.7
pyenv shell 3.4.3
brew --config
Python: /Users/anonymous/.pyenv/shims/python => /Users/anonymous/.pyenv/versions/3.4.3/bin/python3.4
pyenv shell system
brew --config
Python: /Users/anonymous/.pyenv/shims/python => /usr/bin/python
??? Question. If using pyenv’s pythons to brew with is a bad idea, then should I also install brewed versions of python and python3, or would this conflict and cause problems in some way? My options seem to be either use the system python that came installed on my Mac, or use brew’s own pythons for all my brewing needs. In the first case, I could just make sure to call “pyenv shell system” before any brewing, or set some alias to automate this as others have suggested (alias brew="env PATH=${PATH//$(pyenv root)/shims:/} brew"). However, this means I have to use the rather outdated system python. If instead I were to also use brew to install python2 and python3, would this conflict with versions installed using pyenv in any way, or will brew’s pythons live happily completely separate from pyenv’s (I think this is true, but I want to double check before I try it)? Would this give me a setup where all my brewing used brew’s python or python3 (I assume I still need an alias such as that above to make sure pyenv’s versions are not found first in my PATH), and everything else outside of brew would use pyenv’s pythons? Is this a bad idea for any reason?
pyenv global system
*Add to profile:*
alias brew="env PATH=${PATH//$(pyenv root)\/shims:/} brew"
brew install python
brew install python3
??? For example, consider the scenario where I want to use brew to install boost-python with python3 bindings. Does this require a brewed python3 version, and will it subsequently work for a different pyenv version of python 3.x? If I only have pyenv’s versions installed, does the --with-python3 flag even work in this case? On the other hand, if I have brew’s python3 installed in addition to pyenv’s, I assume --with-python3 will link against brew’s python3 (with above alias). If so, will boost-python even be usable when called from a python session running pyenv’s version (not sure if this is more appropriate as a question about boost-python itself), or is this completely fine?
brew install boost
brew install boost-python --with-python3
??? Opinions regarding symlinks for brew that point to pyenv python's? Another post suggested symlinking pyenv's pythons so brew can find them. Besides the obvious caveat that brew now depends on python's that it does not itself manage, is there anything horribly wrong with this idea?
ln -s $(brew --cellar) ~/.pyenv/versions

I'll try to answer each of your questions.
1 Does brew "frown" upon using pyenv's Python rather than brew's?
In short, yes. They lay out the whole story here, and in short you're on your own to manage issue that come up.
2 Will brew Python and pyenv Python conflict?
No. As Tim Smith says in another answer, "nothing bad should happen if you do". Use your PATH to manage which Python you (or an application) sees (and this is what pyenv does).
3 Packages with Python dependency satisfied by brew Python working with "oustide" Python from pyenv
As Tim said, this shouldn't be a problem.
4 Use symlinks so that we only use pyenv Python?
I think you're referring to this post, and it's a fun idea, but likely perilous for maintenance. Fwiw, I'm doing this now.
I lay out how to do it here.

A clarification: Homebrew uses system Python whenever it doesn't make a difference exactly which Python 2.7 it uses (which is pretty common). If you build something --with-python, that will use the first Python in PATH, if that Python is Python 2.7. Otherwise, Homebrew will install and use Homebrew python.
I would not expect that you will find it necessary to install Homebrew's python and python3 but nothing bad should happen if you do. Note that if you use pip or easy_install to install a package that installs scripts (like ipython), those scripts are written so that the package will always be invoked with the python against which it was installed. (You can always get around this behavior by running packages like python -m ipython.) Otherwise, you can control which python you're using just by setting $PATH.
Building boost-python against whatever python 3.4 will work with any other python 3.4. It will probably not work with python 3.5. (This used to be more complicated, but it isn't, anymore!)
Symlinking your pyenv pythons into /usr/local shouldn't hurt but doesn't do anything except put them in $PATH; it won't help Homebrew find them otherwise.

switch versions of python

Story:
One of the app that i have works on python 2.4 and other on 2.6. I tried to do a sym link of python2.4 to python and things started to break loose on ubuntu jaunty.
Now i am downloading every dependency of 2.4 and installing it using python2.4 setup.py install. The dependencies seem to be endless.
Question1: How will i tell any framework that go and use version so and so pf python like day django to use 2.6 and say mjango to use 2.4? Something like we say use database databasename kinda syntax.
Question2: Is there more elegant way to switch between version as my hack of symlinking was a virtual disaster?
Question3: Can I download a deb for say hardy and make jaunty believe its for her?

Use Virtualenv.
There is more information here: Working with virtualenv.
Using virtualenv you can create a new virtual python environment with whatever version of Python you want for each project or application. You can then activate the appropriate environment when you need it.
To expand on my answer:
You can install multiple versions of Python on your computer (I have 2.4, 2.5, 2.6 and 3.1 on my machine - I install each from source). I use a Mac, and keep my system Python as whatever OS X sets as the default.
I use easy_install to install packages. On ubuntu you can get easy_install like this:
sudo apt-get install python-setuptools
To install virtualenv then do:
easy_install virtualenv
I tend to create a new virtualenv for each project I'm working on and don't give it access to the global site-packages. This keeps all the packages tight together and allows me to have the specific versions of everything I need.
virtualenv -p python2.6 --no-site-packages ~/env/NEW_DJANGO_PROJECT
And then whenever I am doing anything related to this project I activate it:
source ~/env/NEW_DJANGO_PROJECT/bin/activate
If I run python now it uses this new python. If I use easy_install it installs things into my new virtual environment.
So, virtualenv should be able to solve all of your problems.

Pythonbrew is a magical tool. Which can also be called as Python version manager similar to that of RVM-Ruby version manager but Pythonbrew is inspired by Perlbrew.
Pythonbrew is a program to automate the building and installation of Python in the users $HOME.
Dependencies – curl
Before Installing the Pythonbrew, Install “curl” in the machine, to install curl use the below command in the terminal, give the the password for the user when prompted.
$sudo apt-get install curl
After Installing the curl, Now Install Pythonbrew, copy and paste the following commands in the terminal and type the password for the user when prompted.
Recomended method of installation - Easy Install
$ sudo easy_install pythonbrew
To complete the installation, type the following command
$pythonbrew_install
Alternate method of installation:
Use curl command to download the latest version of pythonbrew from github.
curl -kLO http://github.com/utahta/pythonbrew/raw/master/pythonbrew-install
After downloading, change “pythonbrew-install” to “executable”
chmod +x pythonbrew-install
Then, run the pythonbrew-install in the terminal
./pythonbrew-install
Now the Pythonbrew has been installed in the “Home Directory” i.e., /home/user/.pythonbrew
Next, copy and paste the following line to the end of ~/.bashrc
*NOTE: change “user” to your user name in the system
source /home/user/.pythonbrew/etc/bashrc
Thats it! Close the terminal.
Steps to Install different versions of Python:
Open a new terminal, type the following command or copy and paste it.
$pythonbrew install 2.6.6
This will install Python 2.6.6 and to install Python 2.7 or Python 3.2, change the version number in the previous command.
$pythonbrew install 2.7
or
$pythonbrew install 3.2
Update: If you get error while Installing then Install using the below command.
$pythonbrew install --force 2.7
or
$pythonbrew install --force 3.2
How to manage different versions of Python installed in system
For instance, if Python 2.6.6, Python 2.7 and Python 3.2 is installed in your system, switching between the versions can be done as follows:
By default, Python 2.6.6 will be active and in order to switch to Python 2.7 use the below command
$pythonbrew switch 2.7
The default Python is changed to Python 2.7.
Now, to switch to Python 3.2 change the version number in the previous command.
$pythonbrew switch 3.2
Use the below command to check or list the installed Python versions
$pythonbrew list
Use the below command to check or list the available Python Versions to install
$pythonbrew list -k
To uninstall any of the installed Python version (for example to uninstall Python 2.7), use the below command.
$pythonbrew uninstall 2.7
Use the below command to update the Pythonbrew
$pythonbrew update
Use the below command to disable the Pythonbrew and to activate the default version
$pythonbrew off
Enjoy the experience of installing multiple versions of Python in single Linux / ubuntu machine!

I find http://github.com/utahta/pythonbrew much easier to install and use than any other solution.
Just install it and you'll have these options:
pythonbrew install 2.7.2
pythonbrew use 2.7.2 # use 2.7.2 for a current terminal session
pythonbrew switch 2.7.2 # use 2.7.2 by default system wide
pythonbrew uninstall 2.7.2
Note: if you're using a Linux-based operating system with preinstalled Python, switching (system wide) to another version can make things go wrong, so be careful.

A more grassroot approach than Virtualenv is the side-by-side installation of two Python versions.
If there is an existing installation, and you want a second installation into the same root path (e.g. /usr/local), use this target when making install:
make altinstall
When your second installation is Python 2.6, this will leave you with a /usr/local/bin/python2.6 alongside the old /usr/local/bin/python.
A simple way to switch between these two versions is using a shell alias (alias python=/usr/local/bin/python2.6) on the shell where you invoke the interpreter. But this won't work across sub-shells and she-bang invocations.

pyenv is yet another Python manager. The README.md at that link has a good set of instructions, but they basically are:
$ cd
$ git clone git://github.com/yyuu/pyenv.git .pyenv
Then set up your $PATH.
$ echo 'export PYENV_ROOT="$HOME/.pyenv"' >> ~/.bash_profile
$ echo 'export PATH="$PYENV_ROOT/bin:$PATH"' >> ~/.bash_profile
$ echo 'eval "$(pyenv init -)"' >> ~/.bash_profile
Install the desired versions of Python:
$ pyenv install 2.7.8
After installing you need to run this:
$ pyenv rehash
Then switch to the version of Python you want to run, for the shell:
$ pyenv shell 2.7.8

"Question1: How will i tell any framework that go and use version so and so pf python like day django to use 2.6 and say mjango to use 2.4?"
You simply run them with the specific python version they need. Run mjango with /usr/bin/python2.4 and django with /usr/bin/python2.6. As easy as that.
"Question2: Is there more elegant way to switch between version as my hack of symlinking was a virtual disaster?"
Yes, see above. Have two separate installs of Python, and run explicitly with the different versions.
"Question3: Can I download a deb for say hardy and make jaunty believe its for her?"
That generally works. If it doesn't, it's because it has dependencies that exist in Hardy, and does not exist in Jaunty, and then you can't.
And here is a Question 4 you didn't ask, but should have. ;)
"Is there an easier way to download all those Python modules?"
Yes, there is. Install setuptools, and use easy_install. It will not help you with library dependecies for those Python modules that have C code and need to be compiled. But it will help with all others. easy_install will download and install all the Python dependencies of the module in question in one go. That makes it a lot quicker to install Python modules.

Move to the project directory :
Create an environment :
virtualenv -p python2.7 --no-site-packages ~/env/twoseven
Then activate your source :
source ~/env/twoseven/bin/activate