The major issue is i only want python3.0+ version of python in my virtualenvironment. But when i create a virtualenvironment with mkvirtualenv then both python2 and python3 gets install inside my virtualenvironments.
Images:
Bashrc Settings :
virtualenv settings :
When you type pythonTab bash shows all pythons in the $PATH — some from /usr/bin/, some from $VIRTUAL_ENV/bin/. virtualenv doesn't separate bash from the system, it only protects one version of Python from the global site-packages/ directory.
If you've configured locate you can see all your pythons using command
locate bin/python
To limit the list for those in $PATH:
for p in ${PATH//:/ }; do
ls $p/python* 2>/dev/null
done
Related
I am using python 2.7 + virtualenv version 1.10.1 for running myproject projects. Due to some other projects requirement I have to work with other version of python(Python 3.5) and Django 1.9. For this I have installed python in my user directory. Also I have dowloaded and installed virtualenv( version - 15.1.0) into my user directory.
But whenever I am trying to create virtual env I am getting the below error
python virtualenv/virtualenv.py myproject
Using base prefix '/home/myuser/python3'
New python executable in /home/mount/myuser/project_python3/myproject/bin/python
ERROR: The executable /home/mount/myuser/project_python3/myproject/bin/python is not functioning
ERROR: It thinks sys.prefix is '/home/myuser/python3' (should be '/home/mount/myuser/project_python3/myproject')
ERROR: virtualenv is not compatible with this system or executable
Can anybody tell what I am doing wrong with this
In Python 3.6+, the pyvenv module is deprecated. Use the following one-liner instead:
python3 -m venv <myenvname>
This is the recommended way to create virtual environments by the Python community.
To create virtual env
virtualenv -p python3 venv_name
This will create new python executable in baseDirectory/bin/python3
How to activate newely created Venv:
cd baseDirectory/bin/
source activate
Deactivate new venv
deactivate
UPDATE_1
This method has been depreciated as The use of venv is now recommended for creating virtual environments.
Please check this link for updated answer
Python already ships with its builtin "virtualenv" called venv since version 3.3. You no longer need to install or download the virtualenv scripts for Python 3.3+.
https://docs.python.org/3/library/venv.html
Check that your installation provided the pyvenv command that should take care of creating the "virtualenv". Arguments are similar to the classic virtualenv project.
$ pyvenv --help
usage: venv [-h] [--system-site-packages] [--symlinks | --copies] [--clear]
[--upgrade] [--without-pip]
ENV_DIR [ENV_DIR ...]
Creates virtual Python environments in one or more target directories.
positional arguments:
ENV_DIR A directory to create the environment in.
optional arguments:
-h, --help show this help message and exit
--system-site-packages
Give the virtual environment access to the system
site-packages dir.
--symlinks Try to use symlinks rather than copies, when symlinks
are not the default for the platform.
--copies Try to use copies rather than symlinks, even when
symlinks are the default for the platform.
--clear Delete the contents of the environment directory if it
already exists, before environment creation.
--upgrade Upgrade the environment directory to use this version
of Python, assuming Python has been upgraded in-place.
--without-pip Skips installing or upgrading pip in the virtual
environment (pip is bootstrapped by default)
Once an environment has been created, you may wish to activate it, e.g. by
sourcing an activate script in its bin directory.
virtualenv is the tool of choice for Python 2, while venv handles the task in Python 3.
Yet you can create the virtual environment for Python 3 using any of them.
Using venv
python3 -m venv virtualenvname
Command Syntax:
/path/to/python3 -m venv /path/to/directory/virtual_env_name
Using virtualenv
virtualenv -p python3 virtualenvname
Command Syntax:
virtualenv -p /path/to/python3 /path/to/directory/virtual_env_name
Activate the virtual environment
On Linux, Unix or MacOS, using the terminal or bash shell:
source /path/to/venv/bin/activate
e.g. source virtualenvname/bin/activate
On Unix or MacOS, using the csh shell:
source /path/to/venv/bin/activate.csh
On Unix or MacOS, using the fish shell:
source /path/to/venv/bin/activate.fish
On Windows using the Command Prompt:
path\to\venv\Scripts\activate.bat
On Windows using PowerShell:
path\to\venv\Scripts\Activate.ps1
Deactivating the virtual environment
On Linux, Unix or MacOS, using the terminal or bash shell:
deactivate
On Windows using the Command Prompt:
path\to\venv\Scripts\deactivate.bat
On Windows using PowerShell:
deactivate
This answer is for those who may use a different OS.
Since the launch of Python version 3.3, there has been no need to download the virtualenv package separately as it comes built-in in Python.
Refer to the documentation to gain complete insights on it.
Test the installation of virtualenv:
$ virtualenv --version
Usage:
1.Creating a virtual environment:
$ virtualenv --system-site-packages -p python3 ./virtual_env_name
2.For enabling it, use the following command:
$ source ./virtual_env_name/bin/activate
3.For disabling the virtual environment and get back to working with the local environment:
$ deactivate
For listing down the packages in the virtual environment, use the
following command:
$ pip3 list
I install it using the command (for Python 3.x),
$ python3 -m venv env
To create a virtual environment in python3:
virtualenv -p /usr/bin/python3 virtualenvname
After creating the virtual environment, we need to activate it using the below command:
source virtualenvname/bin/activate
to deactivate use the below command:
deactivate
If you are on windows.
manually download and install the version of python you want from the official site
after installation, search "python" to locate the folder, so you can identify the path
get the path of the .exe (for example: C:\Users\Path\Programs\Python\Python38\python.exe)
Inside the folder of which you want to create the environment...start bash or VSCode terminal, or whatever command prompt, type [python .exe path] -m venv [env name] like this:
C:/Users/Path/Programs/Python/Python38/python.exe -m venv myenv
(Note that you have to change forward slash to backward slash for the path on step 4)
Activate the environment like so:
source myenv/Scripts/activate
Install virtualenvwrapper on top of virtualenv to simplify things.
Follow the blog to install in easy steps: virtualenvwrapper
Steps to create it:
mkvirtualenv -p /usr/bin/python3
Install packages using - pip install package_name
workon - activates the virtualenv, deactivate - deactivates the viirtualenv
A while ago I had both Python 2.7 and 3.5 installed on my Mac and was able to use them both successfully. Not too long ago, I installed Anaconda and IPython. I have used those for a couple weeks for prototyping and in-console programming.
After I went back to the regular Python for my Django and Flask projects, I discovered an unpleasant thing. Namely, whenever I try to run python or python3 I get the following error:
dyld: Library not loaded: #executable_path/../.Python
Referenced from: /Users/name/anaconda3/bin/python3
Reason: image not found
Abort trap: 6
When I run conda I also get the same error.
If I create a new virtual environment with virtualenv django-project, I am able to activate it, and it allows me to run Python 2.7 successfully.
My question is the following: How can I fix python and python3 for the command line while also retaining the working Anaconda and IPython? How can I make sure that the virtual environments are able to carry Python 3?
I also use macOS and I never mess with or even deal with the system python. I've installed python3 via Homebrew (https://brew.sh) and I always use a virtual environment. I have one in my home directory (my default) and I have one for each project I'm working on.
Your rule of thumb should be to never run 'pip' if you aren't within a virtualenv. Check with $ echo $VIRTUAL_ENV.
To create/recreate the virtual environment in python3 with the currently installed libraries:
Get into your project directory and active your virtualenv.
(optional) Dump your requirements via pip: $ pip freeze > requirements.txt
Nuke your virtual environment directory if you have one: $ rm -rf .venv
Deactivate it: $ deactivate
Create a new one with python3: $ virtualenv -p python3 .venv
Activate it: $ source .venv/bin/activate
(optional) Install your requirements: $ pip install -r requirements.txt
Profit.
You can skip the steps for writing and reading the requirements.txt if you just want to create a new virtual environment and then install only the modules you want/need later.
firstly, to reduce your confusion n which python you are using you could try the following 2 commands in Linux or mac where bash shell is installed:
$ which python
or
$ which python3
in my case, it outputs the python paths I am using with pyenv [with fish shell] [$ is a shell sign]
I am facing following 2 issues:
python command is not using the virtualenvwrapper python.
After activating my virtual environment if I type python then the code still uses the native python libraries. I can easily install libraries etc with pip to my virtual environment but I cannot run any command using python.
e.g. if I execute $ ./manage.py runserverthen it is fine and I can run a django server
but if I try $ python manage.py runserver
or even just
$ python
then it uses the native python libraries and that should not happen
This is while using iterm or terminal in osx. I have never faced this problem in any linux based os
While using any os (linux based or osx), the workon command doesn't work inside any shell script, while it works normally in a terminal
os: osx
sounds like Python might be using the packages in site-packages, which means you should use the --no-site-packages flag when creating your virtualenv (although it seems like this is the default in the current version of virtualenv).
In order to access the virtualenvwrapper functions from a shell script, you will first need to source it: $ source /usr/local/bin/virtualenvwrapper.sh (the path might be different in your case).
You could try install virtualenv and virtualenvwrapper from pip3.
pip3 install virtualenv virtualenvwrapper
And then find where virtualenvwrapper.sh file is:
find / -name 'virualenvwrapper.sh'
I have mine in /usr/local/bin/virtualenvwrapper.sh. But it seems that you have it in some different directory. So you must change below config to fit your needs.
And then in your .bashrc or .zshrc:
# Python3 virtualenv/venvwrapper
export WORKON_HOME=~/.virtualenvs
VIRTUALENVWRAPPER_PYTHON='/usr/bin/python3' # This needs to be placed before the virtualenvwrapper command
export PROJECT_HOME=$HOME/Projects
source /usr/local/bin/virtualenvwrapper.sh # your path to virtualenvwrapper.sh
Let me know if it works :)
I am working on mac OS X Yosemite, version 10.10.3.
I installed python2.7 and pip using macport as done in
http://johnlaudun.org/20150512-installing-and-setting-pip-with-macports/
I can successfully install packages and import them inside my python environment and python scripts. However any executable associated with a package that can be called from the command line in the terminal are not found.
Does anyone know what might be wrong? (More details below)
For example while installing a package called "rosdep" as instructed in http://wiki.ros.org/jade/Installation/Source
I can run: sudo pip install -U rosdep
which installs without errors and corresponding files are located in /opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages
However if I try to run : sudo rosdep init,
it gives an error : "sudo: rosdep: command not found"
This is not a package specific error. I get this for any package installed using pip on my computer. I even tried adding
/opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages
to my $PATH.
But the executables are not found on the command line, even though the packages work perfectly from within python.
I know the question asks about macOS, but here is a solution for Linux users who arrive here via Google.
I was having the issue described in this question, having installed the pdfx package via pip.
When I ran it however, nothing...
pip list | grep pdfx
pdfx (1.3.0)
Yet:
which pdfx
pdfx not found
The problem on Linux is that pip install ... drops scripts into ~/.local/bin and this is not on the default Debian/Ubuntu $PATH.
Here's a GitHub issue going into more detail: https://github.com/pypa/pip/issues/3813
To fix, just add ~/.local/bin to your $PATH, for example by adding the following line to your .bashrc file:
export PATH="$HOME/.local/bin:$PATH"
After that, restart your shell and things should work as expected.
Solution
Based on other answers, for linux and mac you can run the following:
echo "export PATH=\"`python3 -m site --user-base`/bin:\$PATH\"" >> ~/.bashrc
source ~/.bashrc
instead of python3 you can use any other link to python version: python, python2.7, python3.6, python3.9, etc.
instead of .bashrc, choose the rc file from your favourite shell.
Explanation
In order to know where the user packages are installed in the current OS (win, mac, linux), we run:
python3 -m site --user-base
We know that the scripts go to the bin/ folder where the packages are installed.
So we concatenate the paths:
echo `python3 -m site --user-base`/bin
Then we export that to an environment variable.
export PATH=\"`python3 -m site --user-base`/bin:\$PATH\"
Finally, in order to avoid repeating the export command we add it to our .bashrc file and we run source to run the new changes, giving us the suggested solution mentioned at the beginning.
On macOS with the default python installation you need to add /Users/<you>/Library/Python/2.7/bin/ to your $PATH.
Add this to your .bash_profile:
export PATH="/Users/<you>/Library/Python/2.7/bin:$PATH"
That's where pip installs the executables.
Tip: For non-default python version which python to find the location of your python installation and replace that portion in the path above. (Thanks for the hint Sanket_Diwale)
check your $PATH
tox has a command line mode:
audrey:tests jluc$ pip list | grep tox
tox (2.3.1)
where is it?
(edit: the 2.7 stuff doesn't matter much here, sub in any 3.x and pip's behaving pretty much the same way)
audrey:tests jluc$ which tox
/opt/local/Library/Frameworks/Python.framework/Versions/2.7/bin/tox
and what's in my $PATH?
audrey:tests jluc$ echo $PATH
/opt/chefdk/bin:/opt/chefdk/embedded/bin:/opt/local/bin:..../opt/local/Library/Frameworks/Python.framework/Versions/2.7/bin...
Notice the /opt/local/Library/Frameworks/Python.framework/Versions/2.7/bin? That's what allows finding my pip-installed stuff
Now, to see where things are from Python, try doing this (substitute rosdep for tox).
$python
>>> import tox
>>> tox.__file__
that prints out:
'/opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/tox/__init__.pyc'
Now, cd to the directory right above lib in the above. Do you see a bin directory? Do you see rosdep in that bin? If so try adding the bin to your $PATH.
audrey:2.7 jluc$ cd /opt/local/Library/Frameworks/Python.framework/Versions/2.7
audrey:2.7 jluc$ ls -1
output:
Headers
Python
Resources
bin
include
lib
man
share
If you're installing using --user (e.g. pip3.6 install --user tmuxp), it is possible to get the platform-specific user install directory from Python itself using the site module. For example, on macOS:
$ python2.7 -m site --user-base
/Users/alexp/Library/Python/2.7
By appending /bin to this, we now have the path where package executables will be installed. We can dynamically populate the PATH in your shell's rc file based on the output; I'm using bash, but with any luck this is portable:
# Add Python bin directories to path
python3.6 -m site &> /dev/null && PATH="$PATH:`python3.6 -m site --user-base`/bin"
python2.7 -m site &> /dev/null && PATH="$PATH:`python2.7 -m site --user-base`/bin"
I use the precise Python versions to reduce the chance of the executables just "disappearing" when Python upgrades a minor version, e.g. from 3.5 to 3.6. They'll disappear because, as can be seen above, the user installation path may include the Python version. So while python3 could point to 3.5 or 3.6, python3.6 will always point to 3.6. This needs to be kept in mind when installing further packages, e.g. use pip3.6 over pip3.
If you don't mind the idea of packages disappearing, you can use python2 and python3 instead:
# Add Python bin directories to path
# Note: When Python is upgraded, packages may need to be re-installed
# or Python versions managed.
python3 -m site &> /dev/null && PATH="$PATH:`python3 -m site --user-base`/bin"
python2 -m site &> /dev/null && PATH="$PATH:`python2 -m site --user-base`/bin"
The Installing Packages tutorial on python.org describes how to locate the binary directory:
On Windows
You can find the user base binary directory by running
python -m site --user-site and replacing site-packages with Scripts.
For example, this could return
C:\Users\Username\AppData\Roaming\Python36\site-packages so you
would need to set your PATH to include
C:\Users\Username\AppData\Roaming\Python36\Scripts.
On Linux and macOS
On Linux and macOS you can find the user base binary directory by
running python -m site --user-base and adding bin to the end. For
example, this will typically print ~/.local (with ~ expanded to the
absolute path to your home directory) so you’ll need to add
~/.local/bin to your PATH.
I stumbled upon this question because I created, successfully built and published a PyPI Package, but couldn't execute it after installation. The $PATHvariable was correctly set.
In my case the problem was that I hadn't set the entry_pointin the setup.py file:
entry_points = {'console_scripts':
['YOUR_CONSOLE_COMMAND=MODULE_NAME.FILE_NAME:FUNCTION_NAME'],},
On Windows, you need to add the path %USERPROFILE%\AppData\Roaming\Python\Scripts to your path.
Windows and Python 3.9 from MS Store
I have a different path with python -m site --user-base and python -m site - yes, the second command without --user-base to get all sites - as the other answers here state:
C:\Users\<your User>\AppData\Local\Packages\PythonSoftwareFoundation.Python.3.9_qbz5n2kfra8p0\LocalCache\local-packages\Python39\site-packages
Why is my path different
Because I installed python from MS Store
Solution
Put the above path in your path and replace site-packages with scripts
When you install Python or Python3 using MacOS installer (downloaded from Python website) - it adds an exporter to your ~/.profile script. All you need to do is just source it. Restarting all the terminals should also do the trick.
WARNING - I believe it's better to just use pip3 with Python3 - for future benefits.
If you already have Python3 installed, the following steps work for me on macOS Mojave:
Install ansible first using sudo - sudo -H pip3 install ansible
you create a symlink to the Python's bin path
sudo ln -s /Library/Frameworks/Python.framework/Versions/Current/bin /Library/Frameworks/Python.framework/current_python_bin
and staple it to .profile
export PATH=$PATH:/Library/Frameworks/Python.framework/current_python_bin
run source ~/.profile and restart all terminal shells.
Type ansible --version
In addition to adding python's bin directory to $PATH variable, I also had to change the owner of that directory, to make it work. No idea why I wasn't the owner already.
chown -R ~/Library/Python/
I solve the problem!
Use pip3 instead pip.
pip3 install foobaz
vim ~/.zshrc and add:
export PATH="/Users/your_name/Library/Python/3.8/bin:$PATH"
source ~/.zshrc
Now MacOS has shifted the default terminal from bash to zsh. Therefore, you have to source zshrc but not bashrc or bash_profile.
foobaz -v
had the same issue with macOS Monterey. I had to modify my .bash_profile file and add the following entry
export PATH="~/Library/Python/3.8/bin:$PATH"
The default python version on macOS Monterey is 3.8, but you will have to double check your python version to make sure you're using the correct one
Is there a way to force conda to use the system version of python (along with all of the system libraries) in a given env?
I have conda enabled by default in my shell, which can get a bit annoying, because if I try to run a system python app, it gets a different version of python to what it is expecting (python still defaults to 2.7 on *buntu), and often won't run. I would like the root env of conda to just be a redirect to the system python install.
You need to edit all user shell run commands such as your .bashrc file to prepend the bin directory of anaconda to path export PATH=~/anaconda/bin:$PATH, while in your root run commands append export PATH=$PATH:~/anaconda/bin. In both cases you will have access to the conda command. You can check which python will be run by typing $env python --version. You can also check which other versions would be available and their order of priority (if the other is removed) by using $type -a python. Of course ensure your executable python files have #!/usr/bin/env python and not some other direct route to a python executable. For further info Google BASH Shell look up queries like http://www.cyberciti.biz/tips/an-example-how-shell-understand-which-program-to-run-part-ii.html.
Simply removing the python symlink from ~/miniconda3/bin/ appears to do the job.
$ which python
/home/naught101/miniconda3/bin/python
$ rm /home/naught101/miniconda3/bin/python
$ which python
/usr/bin/python
$ source activate science
discarding /home/naught101/miniconda3/bin from PATH
prepending /home/naught101/miniconda3/envs/science/bin to PATH
(science)$ which python
/home/naught101/miniconda3/envs/science/bin/python
(science)$ source deactivate
discarding /home/naught101/miniconda3/envs/science/bin from PATH
$ which python
/usr/bin/python
So far, this doesn't seem to have caused me any problems. Unfortunately the same doesn't work for ~/miniconda/bin/python3, because conda requires it when switching to other envs that use the same python version. However, that one hasn't caused as many problems in the first place.
If this does cause problems, it's easy enough to undo, just cd ~/miniconda/bin/; ln -s python3 python (or what ever version of python you're using in your conda root env). You may need to activate/deactivate an env to get that version of python back on your PATH.
If you are in (base) or another environment, use conda deactivate, this will exit conda's environment and place you back into the OS environment:
on MacOS
(base) user$ python --version
Python 3.9.12
(base) user$ conda deactivate
user$ python --version
Python 2.7.16
on Linux (with no base python installed)
(base) user$ python --version
Python 3.9.15
(base) user$ conda deactivate
user$ python --version
-bash: python: command not found