I am pretty new to python and currenty I am trying to use pylint for checking code quality. I am getting a problem. My pylint doesn't point to virtualenv python interpreter. Here is the output that I get when I run pylint --version
$ pylint --version
pylint 0.21.1,
astng 0.20.1, common 0.50.3
Python 2.6.6 (r266:84292, Jul 10 2013, 22:48:45)
[GCC 4.4.7 20120313 (Red Hat 4.4.7-3)]
In virtualenv I have python 2.7 installed. Will appretiate you help if someone can point me to how to solve that.
A cheap trick is to run (the global) pylint using the virtualenv python. You can do this using python $(which pylint) instead of just pylint. On zsh, you can also do python =pylint.
I am fairly sure that you need to install pylint under your virtual environment and then run that instance of it.
Update - Make life easier:
I would suggest that anybody working a lot in virtual environments create a batch file, (in a known location or on the path), or bash script with something like the following called something like getlint.bat:
pip install pylint
Invoking this after activating the virtual environment will install pylint into that virtual environment. If you are likely to be offline or have a poor internet connection you can, once when you have a good internet connection, (possibly once for each of python 2 & 3):
mkdir C:\Some\Directory\You\Will\Leave\Alone
pip download --dest=C:\Some\Directory\You\Will\Leave\Alone pylint
Which will download pylint and its dependencies to C:\Some\Directory\You\Will\Leave\Alone and you can modify getlint.bat to read:
pip install pylint --find-links=C:\Some\Directory\You\Will\Leave\Alone
It will then use the pre-downloaded versions.
Noufal Ibrahim's answer works if you execute pylint manually.
If you execute pylint from you editor/IDE, you need to configure the plugin correctly.
vim/syntastic
atom/linter-pylint
...
It can get tricky. This may be considered a bug of each IDE/plugin, but that's how it is.
Modifying /usr/bin/pylint to write #!/usr/bin/env python as suggested in another answer fixes this for every use of pylint (manual use, or any editor integration).
However, at least in Debian, using #!/usr/bin/python is a design choice, not a bug. See here for the rationale.
To avoid modifying that system file, one can create a copy of /usr/bin/pylint in /usr/local/bin:
cp /usr/bin/pylint /usr/local/bin/pylint
vi usr/local/bin/pylint # Edit the file to use /usr/bin/env python
This won't be broken by a pylint update, but still infringes Debian's "strongly preferred choice".
This method requires root privileges. An unprivileged user may create an alias
alias pylint='/usr/bin/env python $(which pylint)'.
I always develop in virtualenv and I setup a postmkvirtualenv hook to install pylint and flake8 automatically when creating a virtualenv, so I don't use the versions ditributed by debian anymore.
I ran into this problem, too. My solution was simply to edit the pylint program's shebang, like so... (your path to pylint may be different than mine, though)
$ sudo vim /usr/bin/pylint
Replacing:
#!/usr/bin/python
With:
#!/usr/bin/env python
The issue has been solved on chat (link in comments).
The problem lied in using sudo yum install pylint, because it installed pylint in the global env. The solution was to use the following command:
pip install -i http://f.pypi.python.org/simple pylint
Note the -i usage as the regular index seemed to be broken for the asker.
I know it's been a while since this question was answered, but I just thought I should leave this post here in case someone else runs into the same problem.
If for some reason you need to keep pylint in the global space instead of your virtual environment, you can use the recommendation in here: PyLint + VirtualEnv.
It basically says to configure your pylint using the init-hook and encoding version of a Python program that will use the global pylint and load the rest of the environment.
You can get there by calling the target python interpreter:
./env/bin/python -m pylint ...
# or in an already active env
python -m pylint ...
When you're using Pipenv / virtualenv, install pylint inside the virtualenv:
pipenv install --dev pylint
or, if you don't use Pipenv, install it with pip after you activated your virtualenv:
# activate virtualenv, e.g. `. env/bin/activate`
pip install pylint
I'm using the Syntastic + Pylint combination, and since I have many different virtualenvs that I can work on at any given time, I've created a wrapper over the virtualenv command that, among some other things, installs pylint after all the requirements.
That way, whenever I activate a virtualenv, I'll get its own pylint version.
Hope this helps, and thanks for the tip on deleting the global one from #briford-wylie
Ran into the same problem just today. Continuing on ThorSummoner's answer, when using Pylint with pylint-django inside of a virtual environment such as Pipenv, make sure to call pylint using the target python interpreter (python -m pylint)
A good approach, which will work locally and on your CI as well is to write-down the lint command in the script section of your Pipfile:
[scripts]
lint = "python -m pylint [--options] all-my-modules-names..."
Then calling pylint is as easy as :
pipenv run lint
Related
I've just installed Python version 3.11 (I also moved versions 3.8 and 3.9 to the trash from my Applications folder).
I can see it in the following:
$ myname#name-MBP miniconda3 % ls /usr/local/bin/py*
/usr/local/bin/pydoc3 /usr/local/bin/python3-intel64
/usr/local/bin/pydoc3.11 /usr/local/bin/python3.11
/usr/local/bin/python3 /usr/local/bin/python3.11-config
/usr/local/bin/python3-config /usr/local/bin/python3.11-intel64
(Any additional recommendations on whether I need to clean things up would be much appreciated.)
Checking python3 --version still displays Python 3.8.13.
First attempt to solve
Initially I tried installing it from the command line using homebrew and specifying the version:
brew install python#3.11
I also tried using conda, but neither of these worked.
Second attempt to solve
My initial thought was to check my PATH (I think this is how Python decides which version to use, but please correct me if I'm wrong).
This still only contained version 8 paths:
/Users/myname/miniconda3/lib/python38.zip
/Users/myname/miniconda3/lib/python3.8
/Users/myname/miniconda3/lib/python3.8/lib-dynload
/Users/myname/.local/lib/python3.8/site-packages
/Users/myname/miniconda3/lib/python3.8/site-packages
So I added the Python3.11 path to it using
PYTHONPATH="/usr/local/bin/pydoc3.11/:$PYTHONPATH"
export PYTHONPATH
Now it includes the v3.11 path when I print out sys.path:
/usr/local/bin/python3.11
/usr/local/bin/pydoc3.11
/Users/myname/miniconda3
/Users/myname/miniconda3/lib/python38.zip
/Users/myname/miniconda3/lib/python3.8
/Users/myname/miniconda3/lib/python3.8/lib-dynload
/Users/myname/.local/lib/python3.8/site-packages
/Users/myname/miniconda3/lib/python3.8/site-packages
But the python3 --version output is still unchanged.
Questions
I'm nervous to keep playing around with the contents of my path and entering random command line executions to try to solve this because I really have no clue what I'm doing.
What's happening here?
How can I get the output of python3 --version to be 3.11?
So first thing to understand is setting the variable PYTHONPATH will not affect which version of python is executed by the shell. The shell (bash/zsh) only knows to scan the paths in the PATH env var to figure out all the executables.
Now there are two ways to solve this.
1. Using the python#3.11 from homebrew.
There are several downsides to using this method. Currently, the default python3 by brew is 3.10.x. Whenever you will install any cask or formula that depends on python#3, it'll invariably install the python#3 formula aka 3.10.x. Installing python3 will make brew symlink 3.10.x into /opt/homebrew/bin.
Python 3.11.x can be used by installing python#3.11 and invoking python3.11. This should drop you into the Python 3.11 interpreter. Append all python executable names with the version like pip will be pip3.11
Trying to force 3.11 over 3.10 links will be complicated and cause instability. It'll only cause frustration during development.
2. Using VirtualEnvs
Your best bet for the most stable and no-headache approach to python is to create virtual envs using either venv or pyenv. use pyenv-virtualenv for max ease of use.
One limitation of venv is that it'll create a virtualenv of the same version that invoked it. Aka if you do brew install python#3 && python3 -m venv <folder>, it'll create virtualenv of python3. For 3.11 you'll have to brew install python#3.11 && python3.11 -m venv <folder>. Pyenv on the other hand can install any version of python.
Go through https://www.dataquest.io/blog/a-complete-guide-to-python-virtual-environments/ and https://github.com/pyenv/pyenv-virtualenv to understand and learn more.
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
I have scrooloose/syntastic Plugin install on my vim. And I have installed pylint library globally.
sudo python -m pip install pylint
However for my project I have VirtualEnv and all the necessary libraries for that project is installed in VirtualEnv.
The problem is,
Syntastic shows import error for libraries which are part of virtualenv
My Jedi-vim plugin shows me all the suggestion and I am able to run the problem so there is nothing wrong from python side.
You have to install pylint inside your virtualenv to be recognized by syntastic.
The easiest way is to run
(virtualenv) $ pip install pylint
inside your virtualenv.
If you have too many projects and want to avoid running that command to install pylint to each project you can make vim run it for you. Add the following to your .vimrc:
py3 << EOF
import os
if 'VIRTUAL_ENV' in os.environ:
os.system('pip install pylint')
EOF
This will not avoid using the virtualenv pylint, as this will install pylint to each virtualenv that you open with vim.
I believe it is possible to change the pylint path using g:syntastic_python_pylint_exe but as you can see here, it is not recommended (pylint is dependent on the python version and it would be easy to mess up the versions I guess).
Notice that this approach adds some delay when opening the file, but if you don't mind wait 1 second more to open your file, this approach is interesting.
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.
I've installed virtualenv via pip and get this error after creating a new environment:
selenium:~ auser$ virtualenv new
New python executable in new/bin/python
ERROR: The executable new/bin/python is not functioning
ERROR: It thinks sys.prefix is u'/System/Library/Frameworks/Python.framework/ Versions/2.6' (should be '/Users/user/new')
ERROR: virtualenv is not compatible with this system or executable
In my environment:
PYTHONPATH=/System/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/site-packages
PATH=/System/Library/Frameworks/Python.framework/Versions/2.6/bin:/Library/Frameworks/Python.framework/Versions/2.6/bin:/Library/Frameworks/Python.framework/Versions/2.6/bin:/usr/bin:/bin:/usr/sbin:/sbin:/usr/local/bin:/usr/X11/bin
How can I repair this?
Thanks.
Just in case there's someone still seeking for the answer.
I ran into this same problem just today and realized since I already have Anaconda installed, I should not have used pip install virtualenv to install virtual environment as this would give me the error message when trying to initiate it later. Instead, I tried conda install virtualenv then entered virtualenv env_mysite and problem solved.
Like #RyanWilcox mentioned, you might be inadvertently pointing virtualenv to the wrong Python installation. Virtualenv comes with a -p flag to let you specify which interpreter to use.
In my case,
virtualenv test_env
threw the same error as yours, while
virtualenv -p python test_env
worked perfectly.
If you call virtualenv -h, the documentation for the -p flag will tell you which python it thinks it should be using; if it looks wonky, try passing -p python. For reference, I'm on virtualenv 1.11.6.
In case anyone in the future runs into this problem - this is caused by your default Python distribution being conda. Conda has it's own virtual env set up process but if you have the conda distribution of python and still wish to use virtualenv here's how:
Find the other python distribution on your machine: ls -ls /usr/bin/python*
Take note of the availble python version that is not conda and run the code below (note for python 3 and above you have to upgrade virtualenv first): virtualenv -p python2.7(or your python version) flaskapp
I've run across this problem myself. I wrote down the instructions in a README, which I have pasted below....
I have found there are two things that work:
Make sure you're running the latest virtualenv (1.5.1, of this writting)
If you're using a non system Python as your standard Python (which python to check) Forcefully use the System supplied one.
Instead of virtualenv thing use /usr/bin/python2.6 PATH/TO/VIRTUALENV thing (or whatever which
python returned to you - this is what it did for me when I ran into this issue)
I had the same problem and as I see it now, it was caused by a messy Python installation. I have OS X installed for over a year since I bought a new laptop and I have already installed and reinstalled Python for several times using different sources (official binaries, homebrew, official binaries + hand-made adjustments as described here). Don't ask me why I did that, I'm just a miserable newbie believing everything will fix itself after being re-installed.
So, I had a number of different Pythons installed here and there as well as many hardlinks pointing at them inconsistently. Eventually I got sick of all of them and reinstalled OS X carefully cleaned the system from all the Pythons I found using find utility. Also, I have unlinked all the links pointing to whatever Python from everywhere. Then I've installed a fresh Python using homebrew, installed virtualenv and everything works as a charm now.
So, my recipe is:
sudo find / -iname "python*" > python.log
Then analyze this file, remove and unlink everything related to the version of Python you need, reinstall it (I did it with homebrew, maybe official installation will also work) and enjoy. Make sure you unlink everything python-related from /usr/bin and /usr/local/bin as well as remove all the instances of Frameworks/Python.framework/Versions/<Your.Version> in /Library and /System/Library.
It may be a dirty hack, but it worked for me. I prefer not to keep any system-wide Python libraries except pip and virtualenv and create virtual environments for all of my projects, so I do not care about removing the important libraries. If you don't want to remove everything, still try to understand whether your Pythons are, what links point to them and from where. Then think what may cause the problem and fix it.
I ran into a variation of this "not functioning" error.
I was trying to create an environment in a folder that included the path ".../Programming/Developing..." which is actually "/Users/eric/Documents/Programming:Developing/"
and got this error:
ImportError: No module named site
ERROR: The executable env/bin/python2.7 is not functioning
ERROR: It thinks sys.prefix is u'/Users/eric/Documents/Programming:Developing/heroku' (should be u'/Users/eric/Documents/Programming:Developing/heroku/env')
ERROR: virtualenv is not compatible with this system or executable
I tried the same in a different folder and it worked fine, no errors and env/bin has what I expect (activate, etc.).
I got the same problem and I found that it happens when you do not specify the python executable name properly. So for python 2x, for example:
virtualenv --system-site-packages -p python mysite
But for python 3.6 you need to specify the executable name like python3.6
virtualenv --system-site-packages -p python3.6 mysite
On on OSX 10.6.8 leopard, after having "upgraded" to Lion, then downgrading again (ouch - AVOID!), I went through the Wolf Paulus method a few months ago, completely ignorant of python. Deleted python 2.7 altogether and "replaced" it with 3.something. My FTP program stopped working (Fetch) and who knows what else relies on Python 2.7. So at that point I downloaded the latest version of 2.7 from python.org and it's installer got me up and running - until i tried to use virtualenv.
What seems to have worked for me this time was totally deleting Python 2.7 with this code:
sudo rm -R /System/Library/Frameworks/Python.framework/Versions/2.7
removing all the links with this code:
sudo rm /usr/bin/pydoc
sudo rm /usr/bin/python
sudo rm /usr/bin/pythonw
sudo rm /usr/bin/python-config
I had tried to install python with homebrew, but apparently it will not work unless all of XTools is installed, which I have been avoiding, since the version of XTools compatible with 10.6 is ancient and 4GB and mostly all I need is GCC, the compiler, which you can get here.
So I just installed with the latest download from python.org.
Then had to reinstall easy_install, pip, virtualenv.
Definitely wondering when it will be time for a new laptop, but there's a lot to be said for buying fewer pieces of hardware (slave labor, unethical mining, etc).
The above solutions failed for me, but the following worked:
python3 -m venv --without-pip <ENVIRONMENT_NAME>
. <ENVIRONMENT_NAME>/bin/activate
curl https://bootstrap.pypa.io/get-pip.py | python
deactivate
It's hacky, but yes, the core problem really did just seem to be pip.
I did the following steps to get virtualenv working :
Update virtualenv as follows :
==> sudo pip install --upgrade virtualenv
Initialize python3 virtualenv :
==> virtualenv -p python3 venv
I had this same issue, and I can confirm that the problem was with an outdated virtualenv.py file.
It was not necessary to do a whole install --upgrade.
Replacing the virtualenv.py file with the most recent version sufficed.
I also had this problem, and I tried the following method which worked for me:
conda install virtualenv
virtualenv --system-site-packages /anaconda/envs/tensorflow (here envs keeps all the virtual environments made by user)
source /anaconda/envs/tensorflow/bin/activate
Hope it's helpful.
I had this same issue when trying to install py2.7 on a newer system. The root issue was that virtualenv was part of py3.7 and thus was not compatible:
$ virtualenv -p python2.7 env
Running virtualenv with interpreter /usr/local/bin/python2.7
New python executable in /Users/blah/env/bin/python
ERROR: The executable /Users/blah/env/bin/python is not functioning
ERROR: It thinks sys.prefix is u'/Library/Frameworks/Python.framework/Versions/2.7' (should be u'/Users/blah/env')
ERROR: virtualenv is not compatible with this system or executable
$ which virtualenv
/Library/Frameworks/Python.framework/Versions/3.7/bin/virtualenv
# install proper version of virtualenv
$ pip2.7 install virtualenv
$ /Library/Frameworks/Python.framework/Versions/2.7/bin/virtualenv -p python2.7 env
$ . ./env/bin/activate
(env) $
Open terminal and type /Library/Frameworks/Python.framework/Versions/
then type ls /Library/Frameworks/Python.framework/Versions/2.7/bin/
if you are using Python2(or any other else).
Edit ~/.bash_profile and add the following line:
export PATH=$PATH:/Library/Frameworks/Python.framework/Versions/2.7/bin/
cat ~/.bash_profile
In my case the content of ~/.bash_profile is as follows:
export PATH=$PATH:/Library/Frameworks/Python.framework/Versions/2.7/bin/
Now the virtualenv command should work.
If you continue to have trouble with virtualenv, you might try pythonbrew, instead. It's an alternate solution to the same problem. It works more like Ruby's rvm: It builds and creates an entire instance of Python, under $HOME/.pythonbrew, and then sets up some bash functions that allow you to switch easily between versions. Where virtualenv shadows the system version of Python, using symbolic links as part of its solution, pythonbrew builds entirely self-contained installations of Python.
I used virtualenv for years. It's a decent solution, but I've switched to pythonbrew lately. Having completely self-contained Python instances means that installing a new one takes awhile (since pythonbrew actually compiles Python from scratch), but the self-contained nature of each installation appeals to me. And disk is cheap.