Related
I know the obvious answer is to use virtualenv and virtualenvwrapper, but for various reasons I can't/don't want to do that.
So how do I modify the command
pip install package_name
to make pip install the package somewhere other than the default site-packages?
The --target switch is the thing you're looking for:
pip install --target=d:\somewhere\other\than\the\default package_name
But you still need to add d:\somewhere\other\than\the\default to PYTHONPATH to actually use them from that location.
-t, --target <dir>
Install packages into <dir>. By default this will not replace existing files/folders in <dir>.
Use --upgrade to replace existing packages in <dir> with new versions.
Upgrade pip if target switch is not available:
On Linux or OS X:
pip install -U pip
On Windows (this works around an issue):
python -m pip install -U pip
Use:
pip install --install-option="--prefix=$PREFIX_PATH" package_name
You might also want to use --ignore-installed to force all dependencies to be reinstalled using this new prefix. You can use --install-option to multiple times to add any of the options you can use with python setup.py install (--prefix is probably what you want, but there are a bunch more options you could use).
Instead of the --target or --install-options options, I have found that setting the PYTHONUSERBASE environment variable works well (from discussion on a bug regarding this very thing):
PYTHONUSERBASE=/path/to/install/to pip install --user
(Or set the PYTHONUSERBASE directory in your environment before running the command, using export PYTHONUSERBASE=/path/to/install/to)
This uses the very useful --user option but tells it to make the bin, lib, share and other directories you'd expect under a custom prefix rather than $HOME/.local.
Then you can add this to your PATH, PYTHONPATH and other variables as you would a normal installation directory.
Note that you may also need to specify the --upgrade and --ignore-installed options if any packages upon which this depends require newer versions to be installed in the PYTHONUSERBASE directory, to override the system-provided versions.
A full example
PYTHONUSERBASE=/opt/mysterypackage-1.0/python-deps pip install --user --upgrade numpy scipy
..to install the scipy and numpy package most recent versions into a directory which you can then include in your PYTHONPATH like so (using bash and for python 2.6 on CentOS 6 for this example):
export PYTHONPATH=/opt/mysterypackage-1.0/python-deps/lib64/python2.6/site-packages:$PYTHONPATH
export PATH=/opt/mysterypackage-1.0/python-deps/bin:$PATH
Using virtualenv is still a better and neater solution!
To pip install a library exactly where I wanted it, I navigated to the location I wanted the directory with the terminal then used
pip install mylibraryName -t .
the logic of which I took from this page: https://cloud.google.com/appengine/docs/python/googlecloudstorageclient/download
Installing a Python package often only includes some pure Python files. If the package includes data, scripts and or executables, these are installed in different directories from the pure Python files.
Assuming your package has no data/scripts/executables, and that you want your Python files to go into /python/packages/package_name (and not some subdirectory a few levels below /python/packages as when using --prefix), you can use the one time command:
pip install --install-option="--install-purelib=/python/packages" package_name
If you want all (or most) of your packages to go there, you can edit your ~/.pip/pip.conf to include:
[install]
install-option=--install-purelib=/python/packages
That way you can't forget about having to specify it again and again.
Any excecutables/data/scripts included in the package will still go to their default places unless you specify addition install options (--prefix/--install-data/--install-scripts, etc., for details look at the custom installation options).
Tested these options with python3.5 and pip 9.0.3:
pip install --target /myfolder [packages]
Installs ALL packages including dependencies under /myfolder. Does not take into account that dependent packages are already installed elsewhere in Python. You will find packages from /myfolder/[package_name]. In case you have multiple Python versions, this doesn't take that into account (no Python version in package folder name).
pip install --prefix /myfolder [packages]
Checks if dependencies are already installed. Will install packages into /myfolder/lib/python3.5/site-packages/[packages]
pip install --root /myfolder [packages]
Checks dependencies like --prefix but install location will be /myfolder/usr/local/lib/python3.5/site-packages/[package_name].
pip install --user [packages]
Will install packages into $HOME:
/home/[USER]/.local/lib/python3.5/site-packages
Python searches automatically from this .local path so you don't need to put it to your PYTHONPATH.
=> In most of the cases --user is the best option to use.
In case home folder can't be used because of some reason then --prefix.
pip3 install "package_name" -t "target_dir"
source - https://pip.pypa.io/en/stable/reference/pip_install/
-t switch = target
Nobody seems to have mentioned the -t option but that the easiest:
pip install -t <direct directory> <package>
pip install packageName -t pathOfDirectory
or
pip install packageName --target pathOfDirectorty
Just add one point to #Ian Bicking's answer:
Using the --user option to specify the installed directory also work if one wants to install some Python package into one's home directory (without sudo user right) on remote server.
E.g.,
pip install --user python-memcached
The command will install the package into one of the directories that listed in your PYTHONPATH.
Newer versions of pip (8 or later) can directly use the --prefix option:
pip install --prefix=$PREFIX_PATH package_name
where $PREFIX_PATH is the installation prefix where lib, bin and other top-level folders are placed.
To add to the already good advice, as I had an issue installing IPython when I didn't have write permissions to /usr/local.
pip uses distutils to do its install and this thread discusses how that can cause a problem as it relies on the sys.prefix setting.
My issue happened when the IPython install tried to write to '/usr/local/share/man/man1' with Permission denied. As the install failed it didn't seem to write the IPython files in the bin directory.
Using "--user" worked and the files were written to ~/.local. Adding ~/.local/bin to the $PATH meant I could use "ipython" from there.
However I'm trying to install this for a number of users and had been given write permission to the /usr/local/lib/python2.7 directory. I created a "bin" directory under there and set directives for distutils:
vim ~/.pydistutils.cfg
[install]
install-data=/usr/local/lib/python2.7
install-scripts=/usr/local/lib/python2.7/bin
then (-I is used to force the install despite previous failures/.local install):
pip install -I ipython
Then I added /usr/local/lib/python2.7/bin to $PATH.
I thought I'd include this in case anyone else has similar issues on a machine they don't have sudo access to.
If you are using brew with python, unfortunately, pip/pip3 ships with very limited options. You do not have --install-option, --target, --user options as mentioned above.
Note on pip install --user
The normal pip install --user is disabled for brewed Python. This is because of a bug in distutils, because Homebrew writes a distutils.cfg which sets the package prefix.
A possible workaround (which puts executable scripts in ~/Library/Python/./bin) is:
python -m pip install --user --install-option="--prefix=" <package-name>
You might find this line very cumbersome. I suggest use pyenv for management.
If you are using
brew upgrade python python3
Ironically you are actually downgrade pip functionality.
(I post this answer, simply because pip in my mac osx does not have --target option, and I have spent hours fixing it)
With pip v1.5.6 on Python v2.7.3 (GNU/Linux), option --root allows to specify a global installation prefix, (apparently) irrespective of specific package's options. Try f.i.,
$ pip install --root=/alternative/prefix/path package_name
I suggest to follow the documentation and create ~/.pip/pip.conf file. Note in the documentation there are missing specified header directory, which leads to following error:
error: install-base or install-platbase supplied, but installation scheme is incomplete
The full working content of conf file is:
[install]
install-base=$HOME
install-purelib=python/lib
install-platlib=python/lib.$PLAT
install-scripts=python/scripts
install-headers=python/include
install-data=python/data
Unfortunatelly I can install, but when try to uninstall pip tells me there is no such package for uninstallation process.... so something is still wrong but the package goes to its predefined location.
pip install /path/to/package/
is now possible.
The difference with this and using the -e or --editable flag is that -e links to where the package is saved (i.e. your downloads folder), rather than installing it into your python path.
This means if you delete/move the package to another folder, you won't be able to use it.
system` option, that will install pip package-bins to /usr/local/bin thats accessible to all users. Installing without this option may not work for all users as things go to user specific dir like $HOME/.local/bin and then it is user specific install which has to be repeated for all users, also there can be path issues if not set for users, then bins won't work. So if you are looking for all users - yu need to have sudo access:
sudo su -
python3 -m pip install --system <module>
logout
log back in
which <module-bin> --> it should be installed on /usr/local/bin/
Sometimes it works only works with Cache argument
-m pip install -U pip --target=C:\xxx\python\lib\site-packages Pillow --cache-dir C:\tmp
I noticed that
$ pip3 install virtualenv
installed the script into
~/Documents/bitbucket-python-scripts/.env35/bin though virtual
environment .env35 (created earlier) was not active at the time of
issuing the command.
From ~/.profile
PATH="/home/gsmith/Documents/bitbucket-python-scripts/.env35/bin:$PATH"
export WORKON_HOME=~/Documents/bitbucket-python-scripts/.env35
what is the correct place (dir) where virtualenv is installed? I would
think that virualenv script should not depend on whether I have created
virtual environments or not. Is this correct?
Please also clarify the following. Each created (by virtualenv)
virtual environment has bin and site-packages subdirs. ~/.local also
does. I understand that when I use
(.env35) $ pip3 install aiohttp
a package is installed into the active virtual environment.
When ~/.local is used? Should I setup something additionally?
Using:
Python 3.5.3;
Debian GNU/Linux 9.8 (stretch)
UPDATED 04/29
Through experiment found that if no virtual environments found in the PATH variable, pip3 installs virtualenv script into ~/.local/bin
Our server OS is CentOS 6.8, I was trying to install google-cloud-sdk, even though I installed
python 2.7 in /usr/local/bin
, it is still looking at old version of
python 2.6 in /usr/bin
. I tried giving export PATH=/usr/local/bin:$PATH to first look at /usr/local/bin than /usr/bin but still the problem persists. please suggest a way to fix.
The way I have solved this (and I know it works) is to first install Python 2.7 in whatever way you'd like, then install pip using Python 2.7 which will give you pip2.7. You can then use pip2.7 to install the google_compute_engine module so that it ends up in the right modules folder.
# get pip2.7
wget https://bootstrap.pypa.io/get-pip.py
python2.7 get-pip.py
# install the gcloud module
pip2.7 install google_compute_engine
You can then add this to your $HOME/.bashrc
export CLOUDSDK_PYTHON=/usr/local/bin/python2.7
This is the best repeatable way I know of
Go to the google-cloud-sdk folder and open the install.sh file.
Change the CLOUDSDK_PYTHON="python" value to CLOUDSDK_PYTHON="python2.7"
Rerun the install with the command:
./install.sh
Or you could install it using yum:
https://cloud.google.com/sdk/downloads#yum
If you are on Windows This is a simple solution that worked for me:
open Powershell as administrator and run this to add your Python folder to your environment's PATH:
$env:Path += ";C:\python27_x64\"
Then re-run the command that gave you the original error. It should work fine.
Alternatively you could run that original (error-causing) command within the Cloud SDK Shell. That also worked for me.
I found a CLOUDSDK_PYTHON inside my ~/.bash_profile (or ~/.zshenv).
I removed it, and went back into my google-cloud-sdk directory and reinstalled it.
./install.sh
This fixed the issue for me.
I can't figure out where the shell is trying to run /usr/bin/virtualenvwrapper.sh upon server login. I want virtualenvwrapper permanently uninstalled, not just removed from the shell instance. I thought I uninstalled it with pip uninstall virtualenvwrapper, but every time I log into the server I get the error -bash: /usr/bin/virtualenvwrapper.sh: No such file or directory, as if there is some sort of leftover artifact. Yesterday I did a lot of tinkering and I can't remember all the changes I made or how I made this happen. Where is it executing the search for virtualenvwrapper.sh?
SUPPLEMENTARY INFO
$ echo $PATH
/usr/lib64/qt-3.3/bin
/usr/local/bin/ibm/lsf/9.1/linux2.6-glibc2.3-x86_64/etc
/usr/local/bin/ibm/lsf/9.1/linux2.6-glibc2.3-x86_64/bin
/usr/local/bin
/bin
/usr/bin
/usr/local/sbin
/usr/sbin
/sbin/usr/local/bin/CASAVA-1.8.2/bin
/usr/local/bin/blast
/usr/local/bin/mirdeep2
/usr/local/bin/velvet
$ sudo vim ~/.bashrc
1 # .bashrc
2
3 # Source global definitions
4 if [ -f /etc/bashrc ]; then
5 . /etc/bashrc
6 fi
7
8 # User specific aliases and functions
on ubuntu 12.04 LTS, installing through pip, it is installed to
/usr/local/bin/virtualenvwrapper.sh
And if you are using Ubuntu 16.04 or later, it is installed to
~/.local/bin/virtualenvwrapper.sh
Setting up a Virtual Environment
Now open your terminal in the home directory by right clicking and choosing the option “Open in Terminal”. You can also press the CTRL, ALT, and T keys on your keyboard at the same time to open the Terminal application automatically.
You first need to create a special directory that will hold all of your virtual environments. So proceed with creating a new hidden directory called virtualenv.
$ mkdir .virtualenv
Now you should install pip for Python3.
$ sudo apt install python3-pip
Confirm the pip3 installation.
$ pip3 --version
Now install virtualenv via pip3.
$ pip3 install virtualenv
To find where your virtualenv was installed, type:
$ which virtualenv
Install virtualenvwrapper via pip3:
$ pip3 install virtualenvwrapper
We are going to modify your .bashrc file by adding a row that will adjust every new virtual environment to use Python 3. We will point virtual environments to the directory we created above (.virtualenv) and we will also point to the locations of the virtualenv and virtualenvwrapper.
Now open the .bashrc file using Vim editor.
$ vim .bashrc
If you still haven’t used the Vim editor or you don’t have it installed on your computer you should install it now. It is a widely used Linux editor, and for good reason.
$ sudo apt install vim
After you've installed Vim open the file .bashrc file by typing the vim .bashrc command in your terminal. Navigate to the bottom of the .bashrc file, press the letter i to enter the insert mode of Vim, and add these rows:
#Virtualenvwrapper settings:
export VIRTUALENVWRAPPER_PYTHON=/usr/bin/python3
export WORKON_HOME=$HOME/.virtualenvs
export VIRTUALENVWRAPPER_VIRTUALENV=/home/your_username/.local/bin/virtualenv
source ~/.local/bin/virtualenvwrapper.sh
After you are done, press the esc key. Then type :wq and press enter. This command will save and exit the Vim editor. Close and reopen your terminal when you’re done.
To create a virtual environment in Python3 and activate it immediately, use this command in your terminal:
$ mkvirtualenv name_of_your_env
You should confirm that this environment is set up for Python3:
$ Python -V
To deactivate the environment use the deactivate command.
$ deactivate
To list all available virtual environments use the command workon or lsvirtualenv (same result as workon but shown in a fancy way) in your terminal:
$ workon
$ lsvirtualenv
To activate one specific environment use workon + name of your environment:
$ workon name_of_your_env
There are several useful command you might need to use someday:
Rmvirtualenv will remove a specific virtual environment located in your .virtualenv directory.
$ rmvirtualenv name_of_your_env
Cpvirtualenv will copy the existing virtual environment to a new virtual environment and activate it.
$ cpvirtualenv old_virtual_env new_virtual_env
Well done! You have now created your first isolated Python 3 environment.
There are a number of files that might be run when you login to your terminal if you are using the bash shell.
You should check ~/.bashrc, ~/.bash_profile, ~/.bash_login and ~/.profile for "/usr/bin/virtualenvwrapper.sh".
Likely one of those files is being run on login and contains the missing script which you uninstalled.
It can be that you python packages are installed somewhere else. So try:
$ which python
/home/tesla/miniconda3/bin/python
or
$ which virtualenvwrapper.sh
/home/tesla/miniconda3/bin/virtualenvwrapper.sh
To check the location of python installation. In my case I was using miniconda, therefore system was not able to find the location mentioned in the documentation.
If the above location is not /usr/local/bin/virtualenvwrapper.sh
then now use :
source /home/tesla/miniconda3/bin/virtualenvwrapper.sh
Should work.
UPDATE Nov-2022:
I would recommend using pipenv (official docs) for creating and managing virtual environments.
For anyone finding this in the future. The virtualenvwrapper.sh script is/was now located at /usr/share/virtualenvwrapper/virtualenvwrapper.sh on Ubuntu 20.04.1 LTS (at least for me in my VM).
(Sadly i can't just comment on the above post mentioning the locations so it would all be together, because new user reputation)
sudo -H pip3 install virtualenvwrapper
i ran into to similar problem where installation could not suceed because ~/.cache/pip and ~/.cache/pip/http is not owned by the current user. installing with -H or --set-home option solved my problem.
Confirmed for Ubuntu 18 , as already answered by #Tarique . The shell script virtualenvwrapper.sh for the wrapper is within - ~/.local/bin/
(base) dhankar#dhankar-1:~/opencv_cuda$ cd ~/.local/bin/
(base) dhankar#dhankar-1:~/.local/bin$ ls -ltr
total 100
-rwxr-xr-x 1 dhankar dhankar 41703 Jul 23 20:56 virtualenvwrapper.sh
-rwxr-xr-x 1 dhankar dhankar 2210 Jul 23 20:56 virtualenvwrapper_lazy.sh
-rwxr-xr-x 1 dhankar dhankar 259 Jul 23 20:56 virtualenv
I also confronted the same problem, but this worked for me: -
Create a directory to hold the virtual environments.mkdir $HOME/.virtualenvs
Add a line like export WORKON_HOME=$HOME/.virtualenvsto your
.bashrc.
Add a line like source /path/to/this/file/virtualenvwrapper.sh
to your .bashrc.
Run: source ~/.bashrc
Run: mkvirtualenv temp
This time, the "temp" environment is included.
Run: workon temp
The virtual environment is activated.
If you are on Ubuntu 20 then use the code given below in ~/.bashrc
export WORKON_HOME=~/.virtualenvs
export VIRTUALENVWRAPPER_PYTHON=/usr/bin/python3
export VIRTUALENVWRAPPER_VIRTUALENV=~/.local/bin/virtualenv
VIRTUALENVWRAPPER_PYTHON=/usr/bin/python3
source ~/.local/bin/virtualenvwrapper.sh
In my case on Ubuntu 20, I found this script in:
/usr/share/virtualenvwrapper/
I created an environment with the following command: virtualenv venv --distribute
I cannot remove it with the following command: rmvirtualenv venv -
This is part of virtualenvwrapper as mentioned in answer below for virtualenvwrapper
I do an lson my current directory and I still see venv
The only way I can remove it seems to be: sudo rm -rf venv
Note that the environment is not active. I'm running Ubuntu 11.10. Any ideas? I've tried rebooting my system to no avail.
"The only way I can remove it seems to be: sudo rm -rf venv"
That's it! There is no command for deleting your virtual environment. Simply deactivate it and rid your application of its artifacts by recursively removing it.
Note that this is the same regardless of what kind of virtual environment you are using. virtualenv, venv, Anaconda environment, pyenv, pipenv are all based the same principle here.
Just to echo what #skytreader had previously commented, rmvirtualenv is a command provided by virtualenvwrapper, not virtualenv. Maybe you didn't have virtualenvwrapper installed?
See VirtualEnvWrapper Command Reference for more details.
Use rmvirtualenv
Remove an environment, in the $WORKON_HOME.
Syntax:
rmvirtualenv ENVNAME
You must use deactivate before removing the current environment.
$ rmvirtualenv my_env
Reference: http://virtualenvwrapper.readthedocs.io/en/latest/command_ref.html
You can remove all the dependencies by recursively uninstalling all of them and then delete the venv.
Edit including Isaac Turner commentary
source venv/bin/activate
pip freeze > requirements.txt
pip uninstall -r requirements.txt -y
deactivate
rm -r venv/
If you are using pyenv, it is possible to delete your virtual environment:
$ pyenv virtualenv-delete <name>
Simply delete the virtual environment from the system:
rm -rf venv
(There's no special command for it)
from virtualenv's official document https://virtualenv.pypa.io/en/latest/user_guide.html
Removing an Environment
Removing a virtual environment is simply done by deactivating it and deleting the environment folder with all its contents:
(ENV)$ deactivate
$ rm -r /path/to/ENV
1. Remove the Python environment
There is no command to remove a virtualenv so you need to do that by hand, you will need to deactivate if you have it on and remove the folder:
deactivate
rm -rf <env path>
2. Create an env. with another Python version
When you create an environment the python uses the current version by default, so if you want another one you will need to specify at the moment you are creating it. To make and env. with Python 3.X called MyEnv just type:
python3.X -m venv MyEnv
Now to make with Python 2.X use virtualenv instead of venv:
python2.X -m virtualenv MyEnv
3. List all Python versions on my machine
If any of the previous lines of code didn't worked you probably don't have the specific version installed. First list all your versions with:
ls -ls /usr/bin/python*
If you didn't find it, install Python 3.X using apt-get:
sudo apt-get install python3.X
I used pyenv uninstall my_virt_env_name to delete the virual environment.
Note: I'm using pyenv-virtualenv installed through the install script.
The following command works for me.
rm -rf /path/to/virtualenv
If you are a Windows user and you are using conda to manage the environment in Anaconda prompt, you can do the following:
Make sure you deactivate the virtual environment or restart Anaconda Prompt. Use the following command to remove virtual environment:
$ conda env remove --name $MyEnvironmentName
Alternatively, you can go to the
C:\Users\USERNAME\AppData\Local\Continuum\anaconda3\envs\MYENVIRONMENTNAME
(that's the default file path) and delete the folder manually.
Actually requires two deletions.
The project folder which everyone in this thread already said you simply delete manually or using rm -r projectfoldername
But then you also need to delete the actual virtualenv located in macOS /Users/edison/.pyenv/versions/3.8.0/envs/myspecialenv.
You can do that by doing pyenv virtualenv-delete myspecialenv or manual removal.
if you are windows user, then it's in C:\Users\your_user_name\Envs. You can delete it from there.
Also try in command prompt rmvirtualenv environment name.
I tried with command prompt so it said deleted but it was still existed. So i manually delete it.
cd \environmentfolder_name\Scripts\deactivate.bat
deactivate is the command you are looking for. Like what has already been said, there is no command for deleting your virtual environment. Simply deactivate it!
If you're a windows user, you can also delete the environment by going to: C:/Users/username/Anaconda3/envs Here you can see a list of virtual environment and delete the one that you no longer need.
If you are using pyenv virtualenv < https://github.com/pyenv/pyenv > to centrally manage python versions and virtual environment the solution would be
pyenv uninstall some_env
(Assuming that you have set up your bash .szh profile correctly.)
The solution to this issue is also answered here:
https://github.com/pyenv/pyenv-virtualenv/issues/17
Hope this helps 👍🏻
Just use Anaconda Navigator to remove selected env.
It is possible that some resources will be activated, making it impossible to just delete the directory. All Python processes should be stopped in advance:
pkill -9 python
rm -rf venv
You can follow these steps to remove all the files associated with virtualenv and then reinstall the virtualenv again and using it
cd {python virtualenv folder}
find {broken virtualenv}/ -type l ## to list out all the links
deactivate ## deactivate if virtualenv is active
find {broken virtualenv}/ -type l -delete ## to delete the broken links
virtualenv {broken virtualenv} --python=python3 ## recreate links to OS's python
workon {broken virtualenv} ## activate & workon the fixed virtualenv
pip3 install ... {other packages required for the project}
For the new versions do:
conda deactivate
conda env remove -n env_name
step 1: delete virtualenv virtualenvwrapper by copy and paste the following command below:
$ sudo pip uninstall virtualenv virtualenvwrapper
step 2: go to .bashrc and delete all virtualenv and virtualenvwrapper
open terminal:
$ sudo nano .bashrc
scroll down and you will see the code bellow then delete it.
# virtualenv and virtualenvwrapper
export WORKON_HOME=$HOME/.virtualenvs
export VIRTUALENVWRAPPER_PYTHON=/usr/bin/python3
source /usr/local/bin/virtualenvwrapper.sh
next, source the .bashrc:
$ source ~/.bashrc
FINAL steps: without terminal/shell go to /home and find .virtualenv (I forgot the name so if your find similar to .virtualenv or .venv just delete it. That will work.