After doing a source of the virtual environment I try
pip install -U --no-deps django-social-auth
and it returns:
OSError: [Errno 13] Permission denied: '/usr/local/lib/python2.6/dist-packages/django_social_auth-0.6.9-py2.6.egg-info/dependency_links.txt'
Why is it trying to write outside the virtualenv?
I ran into this problem when I renamed the directory containing my virtual environment. The hard path pip was using was no longer correct.
Update the shebang in the pip script to point to your virtual environment's python executable.
In my opinion, either you are executing a pip that is not part of the virtualenv, or you are, but the python interpreter that gets executed is not part of the virtualenv. Check if the pip you are executing is the right one with which pip, and force the python from the virtualenv by using your_envdir/bin/python pip <arguments>, instead of just invoking plain pip.
This is strange, because if you correctly activated the environment with bin/activate, you should get the correct pip. Are you sure you activated with . bin/activate, and not sh bin/activate ? They are two different things. Did the prompt change ?
you should probably make sure that you the pip from you virtual environment, so sth. like
./env/bin/pip install -U --no-deps django-social-auth
I ran into this problem when I had mistakingly set PYTHONPATH incorrectly in ~/.bashrc. If echo $PYTHONPATH returns anything outside your expected environment, delete it with export PYTHONPATH='' and check your ~/.bashrc for PYTHONPATH.
Related
I'm transitioning to zsh on my Mac (Catalina). So far so good except my virtualenv and virtualenvwrapper aren't working as expected. I've tried re installation with the following steps:
rm -rf ~/.virtualenvs # Delete all existing data.
pip uninstall virtualenv virtualenvwrapper # Remove
pip install virtualenv virtualenvwrapper # Reinstall
Added following lines to ~/.zshrc
export VIRTUALENVWRAPPER_PYTHON=/usr/bin/python2.7
export WORKON_HOME="${HOME}/.virtualenvs"
source `which virtualenvwrapper.sh`
I now have access to the commands in zsh. but if I try to make an env with:
mkvirtualenv testenv
I get:
Using base prefix '/Library/Frameworks/Python.framework/Versions/3.7'
New python executable in /Users/alesirowland/.virtualenvs/bin/python3.7
Not overwriting existing python script /Users/alesirowland/.virtualenvs/bin/python (you must use /Users/alesirowland/.virtualenvs/bin/python3.7)
Installing setuptools, pip, wheel...
done.
running lsvirtualenv returns no environments. It also appears to be trying to use 3.7 despite my environment variables written to default to python2.7. Going back into my bash console creates the env but also defaults to python3. What have I got wrong?
EDITs:
verbose output is generally asking to install in ~/.virtualenvs/bin rather than ~/.virtualenvs//bin
workon on an existing env just echos all of my envs to the screen.
Solution found! this line in my .zshrc is affecting virtualenvwrapper for some reason setopt KSHARRAYS
Working inside a vagrant environment, inside a python virtual environment, when I try to install a python package using
(venv) vagrant#vagrant-ubuntu-trusty-64:~$ pip install <package_name>
I receive a permission error:
error: could not create '/home/vagrant/venv/lib/python2.7/site-packages/<package_name>': Permission denied
When I use sudo to install:
(venv) vagrant#vagrant-ubuntu-trusty-64:~$ sudo pip install <package_name>
the install is successful, but the package is not installed inside venv, but instead inside the global python directory.
I can successfully install the package inside venv by using sudo and specifying the path to pip:
(venv) vagrant#vagrant-ubuntu-trusty-64:~$ sudo /home/vagrant/venv/bin/pip install <package_name>
This is quite convoluted though. So how can I stop sudo pip linking to the global python pip?
Thank you
I had the same problem with pip vs sudo pip and virtualenv pip vs local pip.
I was logged in as root user when I created my venv months ago. So when I wanted to install a new pip package got permission denied. So tried the same command with sudo, but then it installed the package on my local pip.
Lesson learned. I should not use sudo inside a venv.
Fixed it with:
chmod -R 0777 venv_folder_path_here
-R switch for recursive change in venv folder.
And then activate your venv and try pip install:
/home/username_here/venv/project_name_here/bin/activate
(venv_name) pip install package_name_here
The root problem is that sudo does not by default inherit the user's environment as it executes the command. This is what you want - trust me on this.
In your case, your pip is either guided to the venv that it can't write to or - under sudo - to root's environment where you don't want it to be.
The solution you posted is actually valid: If you use sudo, be sure to tell it exactly what to do, how to do it and whom to do it to! All of the aforementioned can be controlled by the user's environment variables so caution is key.
You may also use sudo -E, which does inherit the calling user's environment and should therefore preserve your venv. Be sure to read sudo's man-page or do some googling about all the possible trouble you could get in, though.
Like Daniel said in comments, you should fix the permissions issue with your virtual environment directory. It could be that you already installed something in that directory with sudo. Or you created it with sudo. Which is not ideal. I recommend destroying the virtualenv and then creating it again with the vagrant user. If you are using pyvenv, make sure you pass --copies option.
As user27... said in their answer, the pip you run with sudo is probably not the same pip you run as vagrant user. You can always check that with which pip.
I'd recommend starting with which python inside your python virtual environment. Perhaps you have activated the wrong virtual environment, not related to your vagrant user at all.
I am trying to instal virtualenv and/or virtualenvwrapper on a Mac OS X 10.8.3.
I have been fighting with python for the last two days. Finally I was able to install Python 2.7.4 using brew. Before I had virtualenv installed using easy_install. Then I tried to uninstall it, trying to get my computer in the same situation as the one of my colleagues. Maybe I uninstalled it with success, maybe not. I don't know how to test it. Now I am supposed to install virtualenv using:
pip install virtualenv
But it gives me:
Could not find an activated virtualenv (required).
pip install virtualenvwrapper gives exactly the same output.
Also the variable: PIP_RESPECT_VIRTUALENV is null:
echo $PIP_RESPECT_VIRTUALENV
How can I solve this issue?
Open your ~/.bashrc file and see if this line is there -
export PIP_REQUIRE_VIRTUALENV=true
It might be causing the trouble. If it's there, change it to false and run -
source ~/.bashrc
If not, run export PIP_REQUIRE_VIRTUALENV=false from terminal.
Note: everything works the same if you have .bash_profile instead of .bashrc in your current user's root directory.
#Bibhas has it; +1 to look for export PIP_REQUIRE_VIRTUALENV=true in ~/.profile or ~/.bashrc. You can confirm the setting in your current shell with env |grep PIP_REQUIRE_VIRTUALENV.
This setting is a good safety check; more often than not, you'll want to be installing things into virtualenvs. However, sometimes you do want to be working with the global/system python. In those cases, take a look at --isolated:
Run pip in an isolated mode, ignoring environment variables and user configuration.
$ pip install --upgrade pip
Could not find an activated virtualenv (required).
$ pip install --upgrade pip --isolated
Requirement already up-to-date: pip in /usr/local/lib/python2.7/site-packages
$ pip freeze --isolated
...
An additional solution to those already presented is to add a shell command that will allow you to install py packages by temporarily overriding the default setting. Add this to your ~/.profile, ~/.bashrc or wherever you maintain your shell's exports/settings (in my case, ~/.zshrc).
syspip(){
PIP_REQUIRE_VIRTUALENV="" pip "$#"
}
With this simple addition, you can install pip packages to the system via syspip install <package>.
Verify contents of ~/.pip/pip.conf like:
[global]
index=https://pypi.python.org/simple/
require-virtualenv=false
if previous it was set like require-virtualenv=true
Another place where you may possibly have this "lock" is the pip.conf file. In my case I had one in my ~/Library/Application Support/pip folder and forgot about it.
Typical content of the file could be:
[install]
require-virtualenv = true
[uninstall]
require-virtualenv = true
Similar to other answers, false should be changed to true in the file.
Important to heed #JCotton's advice here-- keeping your pip setup so as to only install into virtualenvs is a great practice.
His solution to get virtualenv setup again of pip install --upgrade pip --isolated is exactly what should be done.
You should NOT turn off requiring a virtualenv, either by config file or by editing ~/.bash_rc or ~/.bash_profile, to get your project's pip packages installed. We're only doing it here because OP needs virtualenv itself installed.
In general, I see people get this message when their virtualenv wasn't setup correctly for their project in the first place. Reminder that to create a virtualenv with its own python and pip so that you don't run into the "could not find an activated virtualenv" error, you run virtualenv -p python3
for matchbook you must go to '.bash_profile '
1) open with your favorite editor in terminal
nano .bash_profile OR vim .bash_profile
2) find the text line that says
export PIP_REQUIRE_VIRTUALENV=true
3) delete it or set it equal to "false"
4) finally restart your terminal
When I activate a venv, which pip returns /usr/local/bin/pip instead of path/to/my/apps/venv/bin/pop. Why is that?
I am inclined to just rm- rf the pip in /usr/local/bin/pip and install again, but since this is a production server I prefer not to guess too much :-)
My concern is that I have (in usr/local/bin):
easy_install
easy_install-2.6
pip
pip-2.6
virtualenv
virtualenv-2.6
python --version returns 2.6.6 and which python returns /usr/bin/python even though venvis activated?
Running Debian Squeeze
Check your virtualenv for a local directory. If venv/local exists, does it contain pip and easy_install? If it does, you can try working around this problem by editing venv/bin/activate and prepending venv/local/bin to your path just like venv/bin is being prepended.
Something like:
_OLD_VIRTUAL_PATH="$PATH"
PATH="$VIRTUAL_ENV/bin:$PATH"
PATH="$VIRTUAL_ENV/local/bin:$PATH" # my new line
export PATH
I'm having a problem similar to what I've described, and unfortunately I have not run it to ground yet. See also: Why do distribute and pip install to my virtualenv's ./local/bin?
What shell are you using? What specific command did you use to activate the virtualenv?
In my case (also using squeeze) I am using bash and it if I run "source bin/activate" then everything in my path (pip, python, etc) is correct.
After using virtualenv with pip off-and-on for a couple of days, I've found that the version of PIP that is used after the virtualenv is actived is the global PIP instead of the PIP relative to that environment; such that if you don't set the shell environment variable export PIP_RESPECT_VIRTUALENV=true, pip will install whatever new package (e.g. pip install argparse) to the global scope instead of only to the virtualenv.
I would expect PIP to install to the virtualenv by default, if that virtualenv is activated.
Is there a reasoning behind it not working that way by default?
See explanation here for how PIP_RESPECT_VIRTUALENV works.
When you create a virtualenv, the activate file hardcodes the variable VIRTUAL_ENV to the location in which you first created the root directory. This variable is then exported when you source <your-venv>/bin/activate.
Consequently, if you move the virtualenv directory subsequent to its creation, the hardcoded file path will be incorrect.
Just open <your-venv>/bin/activate in a text editor and make sure VIRTUAL_ENV is set to the new path of your virtualenv directory:
VIRTUAL_ENV="/Full/path/to/<your-venv>"
export VIRTUAL_ENV
before running source <your-venv>/bin/activate again.
Then of course you can test the version of pip with which pip which should produce:
/Full/path/to/<your-venv>/bin/pip
rather than /usr/bin/pip or /bin/pip etc.
It is not the first time I see someone reporting the same issue. I don't know what is happening, but some people discourage the use o source /path/to/venv/bin/activate because it can mess up your $PATH.
There is a way pip will always respect your virtualenv: don't rely on $PATH. Use:
/path/to/venv/bin/pip install MYPACKAGE
It would be nice to find out what is happening to you and share your solution with others. Meanwhile, it may be ok to use the absolute path to pip.