Develop Reference

Can not run Ansible after installing python 3.10

Suddenly I cannot run ansible.
Whenever I try any ansible command like ansible-playbook, ansible version, etc. it shows error
`/Users/myusername/Library/Python/2.7/bin/ansible: /System/Library/Frameworks/Python.framework/Versions/2.7/Resources/Python.app/: bad interpreter: No such file or directory`,
Even if I let ansible run different python version, like ansible-playbook --version -e 'ansible_python_interpreter=/usr/bin/python3, it shows the same error.
FYI: which ansible returns /Users/myusername/Library/Python/2.7/bin/ansible
I guess it is related to my recent installation of python. Since I installed a python3.10 recently, The python2.7 becomes not work. Note I did not remove anything about python2.7 myself. looks like the installation of python3.10 changed python2.7 setting.
For most other application, I now pointed the system to use python3 as workaround, e.g. I set CLOUDSDK_PYTHON=/usr/bin/python3 to make accessing cloud cli works again. But for Ansible, I have not figured out how to make it work. I am using MacOS terminal.
Does anybody know how to resolve the above issue so that I can run ansible again? Anyway is OK as long as I can run ansible. Either reinstall ansible and let it use python3 instead of using Python2.7 or guide me how to reinstall python2.7 (in a right way, not messy with python3.10, currently I am scared of installing python, I am afraid if I reinstall python2.7, both python3.10 and 2.7 will be out of work then I cannot work).
Please help. Thanks.

You will have to do some cleanup on your system because somehow, Python 2.7 was removed from you system. This might have happened due to updating to macos 12.4 Monterey at some point, because Monterey 12.3 and newer removed the system-provided Python 2.7, replacing it with a Python 3.8.9 installation (/usr/bin/python3).
However, you still have stuff in your environment that reference all those Python 2.7 things, like your ${HOME}/Library/Python/2.7/bin/ansible directory.
Here are the things you can do to (hopefully) make ansible and your environment work again.
Change your shell's PATH environment.
You're probably using zsh since it's the default shell on macos. Have you ever changed your .zshrc or other environment files to add /Users/<name>/Library/Python/2.7/bin in your PATH? You will need to remove that.
Additionally, if you strictly want to use the Python 3.10 you manually installed (and not Monterey's system-provided /usr/bin/python3 which is python v3.8.9), you will probably need a PATH that looks like this...
# somewhere in your ~/.zshrc, probably near the bottom
export PATH="/Library/Frameworks/Python.framework/Versions/3.10/bin:${PATH}"
Re-install Ansible
With whatever python3 binary you're using, re-install ansible
python3 -m pip install --user ansible
This will end up installing ansible into ${HOME}/Library/Python/<VERSION>/bin
Update PATH again to include new bin dir
Building on part (1) above, you want to include the bin directory for Python stuff in your user directory, to be able to refer to anything installed by pip install --user.
# somewhere in your ~/.zshrc, probably near the bottom
export PATH="${HOME}/Library/Python/3.10/bin:${PATH}"
export PATH="/Library/Frameworks/Python.framework/Versions/3.10/bin:${PATH}"
Reload your shell and try to run ansible
# if you already have a shell open, run this
# to reload your zsh configs
exec zsh
# hopefully this returns the correct path!
which ansible
# and hopefully this runs!
ansible --help
Reinstall Anything Else You Need
You reference stuff like CLOUDSDK_PYTHON which sounds like you also have stuff like the gcloud module installed. Time to reinstall those with your new Python.
python3 -m pip install --user gcloud
# and whatever else needs reinstalling
Hopefully this all fixes your environment. Now you can clean up the remnants of Python 2.7 stuff from your home directory once everything else is working, as this directory has broken module installs that reference a deleted system Python anyway.
cd ~/Library/Python
rm -rf 2.7

Using Spyder with Python 2.7 and Python 3 on Linux

I am working on a Python 2.7 program. I am not used to use Spyder, I usually use vanilla Python form the terminal. Since my calculation are quite heavy I would like now to use Spyder just to do the plotting without having to run the whole calculation. Basicly I want to use the Spyder because it keeps the variables in a workspace and because it provides the possibilty of messing around with the plotting without having to run a full calculation every time.
I installed Spyder with
sudo apt install spyder
How should I use this installation to choose whether Python 2.7 or Python 3?
What I tried
I also tried to install Spyder throught pip as suggested here like so
python -m pip install spyder
which is not working. So I forced pip to install a specific version of Spyder with
sudo pip install -Iv spyder==2.3.9
but again there is an issue with dependencies. And even if it had worked, it wouldn't have allowed me to select the version of Python. It would only have installed a version of Spyder that works with Python 2.7.
Changing Python interpreter as suggested here doesn't work either. I tried to specify bin/python as Python interpreted but it doesn't work with the IPython kernel.
Solution
As mentionned below the solution is to use conda and virtual environments for each Python version.

I'm not sure if I got your question right,
but if you are not sure how to change the Python interpreter in Spyder, then take a look into this post: How to change python version in anaconda spyder
If you want to run spyder,
just type spyder into your terminal.
If you want to use multiple versions of python consider to use virtual environments created by virtualenv or conda.
For this, take a look into this article: Conda: Creating a virtual environment
Rgds

problem with newly installed pip (or maybe with python 3.7 as well)

I got confused with how to source activate the correct venv.
I used to use pip v10. I have a working venv called "base_py36" and I could source activate base_py36 with everything OK.
Recently I upgraded pip to pip v19. Now when I run source activate base_py36, it goes into the venv but all my installed packages are gone.
PS: when I searched the venv directory, I found that under /anaconda3/envs/base_py36/lib I have both python3.6 and python3.7 with different packages. So could this be the reason? (I cannot remember when I installed python 3.7). If so how could I source activate base_py36 with python 3.6?

I'm going to assume you mean "with python 3.7" at the end.
But yes, that is the most likely cuplrit. For a quick, albeit lazy, workaround, you can just copy the modules from Python 3.6 to Python 3.7. Since there is so little difference between the two, they're guaranteed to be forward compatible, at least for now.
Also, if that doesn't work, could you activate the virtual environment, and tell us what version of python it's running?

Pip not installing Python modules to proper directory

So I downloaded a module, but when I tried to use it in a program, Python threw the error:
"ImportError: No module named markovify"
When I go to try to change my .bash_profile, it shows this:
"# Setting PATH for Python 3.5
The orginal version is saved in .bash_profile.pysave
PATH="/Library/Frameworks/Python.framework/Versions/3.5/bin:${PATH}"
export PATH"
I've been using 2.7.10 all this time, and Terminal defaults to it. (When I type in Python, that's the version it says I'm using)
I'm trying to get pip to install modules for python 2.7.10 to a different folder.
What's weird is this: I seem to have installed pyparsing with pip and it seems to work. I tried installing markovify and it throws this error message.
What am I missing?

When I go to try to change my .bash_profile, it prints this
That suggests you're using some tool to change your profile. Did you also use that tool to install markovify? You need to be clear about your environment when you have environment questions! :-)
If you installed markovify from the command line, I'd suggest opening a new terminal and running these commands, just to make sure you're working from where you think you are:
$ python --version
Python 2.7.10
$ command -v python
/usr/bin/python
The most likely problem, it seems to me, is that you got a bit tangled up and wound up doing something other than what you intended. From a fresh start, provided you're starting with the environment you want, pip should, you know, Just Work.
I'm trying to get pip to install modules for python 2.7.10 to a different folder.
That's possible to do, but are you sure that's what you want? Usually if you're using the Python interpreter you intend to, and haven't putzed with PYTHON_PATH & friends, when you run pip, it will install to its default location, which sure enough is where Python will look for it when you say to import it.
As an experiment, you might check if markovify was somehow installed for Python 3.5. Try
$ /Library/Frameworks/Python.framework/Versions/3.5/bin/python -c 'import markovify'
(You might also want to check that the Python interpreter is in fact in that folder and has that name.)

When you're working on more than one Python version, you should work on Virtual Environments:
Virtual Env on Hitchhiker's Guide

"Proper way" to manage multiple versions of Python on archlinux

So I have read this - https://wiki.archlinux.org/index.php/Python
And it is clear from this wiki that I can install Python 2.7.2 via
pacman -S python2
Is it reasonable for me to create a symlink to python2
ln -s python2 /usr/bin/python
if I don't forsee myself switching to python 3.0 any time soon? Or is there a better way of managing multiple python versions like what I usually use on a debian system (update-alternatives --config python) or on a mac os x system (python select)?
CLARIFICATION:
What I am trying to find out is - what is the "best practice" of managing various python versions on an archlinux system?
I am new to archlinux but familiar with ubuntu, debian and mac os x

I would argue you shouldn't create any symlinks like this at all. Especially if you are going to distribute some of your python code, you should not assume a user has python2 or python3 at /usr/bin/python.
If your script requires python2, just use:
#!/usr/bin/env python2
If your script requires python3, use:
#!/usr/bin/env python3
This way your scripts will work fine even through updates to Python. It will also be much more clear what version your script actually needs.

Most unices already have a /usr/bin/python. Overwriting that one is a bad idea, as this is the Python version used by all packages in the system, and changing that one may break them. When installing the Python 2.7 package the executable should be installed as /usr/bin/python2.7 (if not I would claim Archlinux is broken) and it's better to use that when you want to run Python 2.7.
Archlinux is a bit special, since it will use /usr/bin/python for Python 3, despite the default executable name for Python 3 being /usr/bin/python3. This is confusing and can be seen as a bug, but it does mean you can't use that symlink for Python 2, as any other Archlinux script that uses Python 3 will almost certainly break if you do.
So where on other Unices, symlinking /usr/bin/python to Python 2.7 is a bad idea, on Archlinux it is a terrible idea. Instead just install all version you need and call them with /usr/bin/pythonX.X.

There is a nice project on github what helps you with it's called pyenv
What helps you to manage multiple python instances

As others have said, the short answer is "don't do this, it will most likely break things on your system", however, if you mostly use Python 2 you can still set your personal default in your shell (and still have the option of switching to Python 3 at any time). To do this, first become root and install python2-virtualenv:
# pacman -S python2-virtualenv
Then create a virtual environment that uses Python 2 (this will automatically install Python, setuptools, wheel, and pip in the environment):
$ virtualenv -p /usr/bin/python2 --system-site-packages ~/env # (Or wherever you want your environment to live)
If you only want to use locally installed packages (eg. packages you install with pip and not the ones installed by pacman) remove the --system-site-packages option when creating your environment.
Now in your ~/.bash_profile or ~/.profile (or whatever your preferred shells configuration file is), set something like the following:\
source ~/env/bin/activate
This will activate the virtual environment, making your default version Python 2.
This could still break anything that is launched in a shell, but it's not likely that anything will be unless you're explicitly running it from a shell, at which point you can turn the virtual environment off by running:
deactivate
or simply manually run Python 3.

I just stumbled over this post, no necro-bumping intended but I was wondering nobody mentioned virtualenvs. I'm using ArchLinux as well and I use the python packages virtualenv and virtualenvwrapper to create multiple python environments. You can reference to the python 2 or python3 binaries in /usr/bin/ to determine the python version used in the virtual environment.
The benefit is that packages installed in a virtual environment don't mess with the python the system is using and there are many ways to automate project handling.

I know this may be a very old answer, but it took me two days to solve the problem so I'm going to share.
The proper way to manage python versions in your system to work on different projects without them driving you crazy is to use pyenv and its plugins pyenv-virtualenv and pyenv-virtualenvwrapper as described by Henrique Bastos into this blog post. Notice that this way to work is kinda platform independent, since pyenv is a python package and it can be run quite similarly on Windows, Linux and Mac OSx.
The problems start with Arch Linux. The OS doesn't provide a pacman version of pyenv, so you have to install it cloning it from github as described in the installation section of the release. The installation process is the same both for pyenv-virtualenv and pyenv-virtualenvwrapper. Notice that the shell initialization configuration may be different, in my case it didn't work for ~/.bash_profile, but worked for ~/.bashrc .
Running pyenv is not straightforward if your installation is very fresh like the one I'm setting up in these days, since pip requires openSSL and even if you install it via pacman, pyenv doesn't see it. So, if you want to install an older version of Python (namely 3.4.3), you will find the shell complaining about you haven't installed the openSSL plugin, even if you have it. To be honest, I didn't have the right packages the first time I tried to install it; you have to download the following packages
sudo pacman -S openssl
sudo pacman -S openssl-1.0
sudo pacman -S python-pyopenssl
sudo pacman -S python2-pyopenssl
The way I solved the problem is to add the flags as described in the pyenv installation FAQs: that solution eventually led me to install the python version I wanted:
LDFLAGS="-L/usr/lib/openssl-1.0" \
CFLAGS="-I/usr/include/openssl-1.0" \
pyenv install -v 3.4.3
To avoid to go on the FAQs page everytime you want to renew the python installation environment, you can add an alias in ~/.bashrc or whatever is you shell as follows:
echo alias pyenv='LDFLAGS="-L/usr/lib/openssl-1.0" \
CFLAGS="-I/usr/include/openssl-1.0" \
pyenv' >> ~/.bashrc
In this way you can install python properly with a clean pyenv syntax, and manage it via its plugins in the same way (since the syntax is pyenv [COMMAND] [OTHERSTUFF]).

No, there is no better way to do this. The python symlink is part of the Python 3 package.
I guess changing this link won't break anything for now but it might be possible that some packages will depend on it in the future.