Using OSX 10.9.2
Just getting to grips with virtualenv and virtualenvwrapper. I am having an issue where the environments I create with virtualenv are visible in both terminal and finder, but environments that I create with virtualenvwrapper are not.
Here are the steps I take in terminal.
virtualenv virt_env/virt1 --no-site-packages
Successfully creates a virtualenv called virt1
source virt1/bin/activate
Activates the virtualenv
(virt1)localhost:virt_env brendan$
I have several of these virtual environments set up and working and I am able to install packages in each, as I would expect. I am able to switch between them and remove them as necessary. I am also able to see them in Finder and in Terminal.
However when I create virtual environments using virtualenvwrapper it appears that I am able to work with them but I am not able to see them.
Here are the steps I take with virtualenvwrapper
localhost:~ brendan$ mkvirtualenv virt_env/virt4
New python executable in virt_env/virt4/bin/python
Installing setuptools, pip...done.
(virt4)localhost:~ brendan$
I am able to work with this e.g.
(virt4)localhost:~ brendan$ sudo easy_install yolk
And I am able to deactivate and reactivate it. e.g.
deactivate
localhost:~ brendan$
workon virt_env/virt4
(virt4)localhost:~ brendan$
But when I go to finder I am only able to see the environments (virt1, virt2, virt3) that I created via virtualenv and not the environments (virt4) that I created using virtualenvwrapper
I am using these tutorials
Virtualenv
Virtualenvwrapper
Make sure that you've defined your WORKON_HOME environment variable to tell virtualenvwrapper where to put your environments (see the documentation)
MacOS X is a Unix-based system, and so doesn't list files and directories whose names begin with a dot. You are probably storing your virtualenvs is a directory called .virtualenvs, which is therefore invisible.
For details of how to find the pesky thing see, for example, http://www.macosxtips.co.uk/index_files/quickly-show-hidden-files.php
Related
I create a new project with the following commands:
mkdir ~/my_project
python -m venv ~/my_project
source ～/my_project/Scripts/activate
pip install flask
pip install kivy
pip install foo
pip install bar
And let's say that I decide to remove my_project and create a new project:
rm -rf ~/my_project
mkdir ~/new_project
python -m venv ~/new_project
source ~/Scripts/activate
Questions:
What happens to previously installed packages "flask", "kivy", "foo", and "bar"? Do I need to re-install them for my new_project's virtual environment?
If I don't need to re-install these packages, then I am missing the point of virtual environment? I thought the whole point of virtual environment is that packages installed in the virtual environment is isolated in that environment. Can someone elaborate?
Indeed, pip installs libraries into a subdirectory of the virtualenv when the env is active. Anything in there is independent of any system-wide installs, and vice versa. Removing the env obviously removes the stuff in the subdirectories.
On the other hand, virtualenv can optionally fall back to system-installed packages if you let it. The system-wide installs will obviously still be there after you remove the virtualenv.
As an aside, the current activate hard-codes some things so that you cannot even rename a virtualenv directory; you have to zap and reinstall it. Keeping all the things it needs in a requirements.txt or similar is a good way to simplify this process, as well as document the dependencies.
The point of Virtual Environment is to separate your development environment from your actual environment. Different projects have different package dependencies. So for these cases Virtual Environment comes in handy.
If you installed flask, kivy, foo, and bar inside a virtual environment, then YES, you need to install them when you move into another Virtual Environment (That's the whole purpose of Virtula Environment).
If you find that the packages are available globally then may be you are not using it correctly. You need to activate your Virtual Environment before you install anything or the packages will be installed globally.
For your case I can see you are activating before installing packages. So it should work right. you can always use pip freeze to see what packages are installed.
I'm trying to start up a virtual env using virtualenv, am getting this error:
Already using interpreter /Users/pkilcrease/anaconda/bin/python3
Using base prefix '/Users/pkilcrease/anaconda'
New python executable in /Users/pkilcrease/.virtualenvs/bodega/bin/python3
Also creating executable in /Users/pkilcrease/.virtualenvs/bodega/bin/python
ERROR: The executable /Users/pkilcrease/.virtualenvs/bodega/bin/python3 is not functioning
ERROR: It thinks sys.prefix is '/Users/pkilcrease/.virtualenvs' (should be '/Users/pkilcrease/.virtualenvs/bodega')
ERROR: virtualenv is not compatible with this system or executable
The command I am running is mkvirtualenv -a . --no-site-packages --python='which python3' -r requirements.txt bodega
My .bashrc file currently looks like this:
export WORKON_HOME=$HOME/.virtualenvs
export VIRTUALENVWRAPPER_SCRIPT=/Users/pkilcrease/anaconda/bin/virtualenvwrapper.sh
source /Users/pkilcrease/anaconda/bin/virtualenvwrapper_lazy.sh
I have the feeling that there is some issue with anaconda and virtualenv which is causing the problem here, but not sure how to remedy that or if it's just a red herring.
If using a conda python executable, use conda create --name {your_venv} python=3 (note there is a virtualenv utility that comes with conda, but still use conda create... to make new virtual env's).
Otherwise, when using a version of python installed by the system package manager, create a virtual env using virtualenv, or preferably using the virtualenvwrapper utility mkvirtualenv. For example on Linux, the "system python" is /usr/bin/python3, /usr/bin/python, /usr/bin/python2, etc. Or, as it's clear you're on MacOS, that would likely be a python installed by brew (homebrew) or port (macports) in /opt or /usr/local. You may have to install virtualenvwrapper in order to get mkvirtualenv (and lsvirtualenv, etc).
In short, if you're using anaconda python, stick with conda utils. Else, if you're keeping your python free & open (as many of your corp IT data centers do), then use any of the various open utils like mkvirtualenv, etc.
Hopefully this may help people still looking at this question, but an easy fix:
conda install -y virtualenv
Simple question: is running homebrew while in a virtualenv a bad idea?
If so, is there any way that I can automatically deactivate the virtualenv each time I run a homebrew command? I don't trust myself to always remember to deactivate the virtualenv or open a new terminal window.
Since I just ran across this myself in the documentation, it's probably better in general not to brew install from within an active virtualenv. To quote from said docs:
WARNING: When you brew install formulae that provide Python bindings, you should not be in an active virtual environment.
Activate the virtualenv after you've brewed, or brew in a fresh Terminal window. Homebrew will still install Python modules into Homebrew's site-packages and not into the virtual environment's site-package.
Virtualenv has a switch to allow "global" (i.e. Homebrew's) site-packages to be accessible from within the virtualenv.
As such, if you are certain the formula you are brewing will not attempt to provide new Python bindings then let it rip. But for me, if there's no specific reason to brew install with my virtual environment activated, I try and remember to deactivate beforehand.
I don't think if they are related. You have to use pip for python package management when you use virtualenv. this way you make sure that your new stuff is on the sandbox you created. AFAIK home-brew installs stuff globally. So better not use it to get the python modules. hope it helps.
Okay so I have installed virtualenv and with tha I have got my pip installed.
Then, I have installed virtualenvwrapper using sudo pip install virtualenvwrapper, and also have set up my $WORKON_HOME variable and settings.
Now I have a doubt, if I switch to some random directory say cd ~/Code/Django/
and create an env there using virtualenv env1
who will handle it, I mean, can I use virtualenvwrapper with it and why does it not show up when I do workon, only the environments in the ~/.virtualenvs/ show up.!
And would this new environment be as secure as the one created by the virtualenvwrapper???
Please tell me if I am wrong somewhere!!
workon gets list of virtual environments from WORKON_HOME environment variable, that points to ~/.virtualenvs in your case (default).
Quote from docs:
The variable WORKON_HOME tells virtualenvwrapper where to place your
virtual environments. The default is $HOME/.virtualenvs. If the
directory does not exist when virtualenvwrapper is loaded, it will be
created automatically.
Hope that helps.
I've currently got a working installation of the Enthought Python Distribution on my machine that I don't want to necessarily disrupt, but I'd like to look at moving over to Anaconda from Continuum.
I can easily install Anaconda into the virtualenv directory I create, but I'm not sure how to tell that virtualenv to use the anaconda-version of Python. If I was telling my whole system to use it I can alter .bash_profile with something like export PATH="/DIRECTORIES/anaconda/bin:$PATH. Is there a way to do that within a virtualenv?
I just tested the Anaconde 1.6 installer from http://continuum.io/downloads
After downloading, I did:
bash Anaconda-1.6.0-Linux-x86_64.sh
If you take the defaults, you'll end up with a directory anaconda in your home directory, completely separate from your EPD or system Python installation.
To activate the anaconda installation's default environment, do the following:
source $HOME/anaconda/bin/activate ~/anaconda
All Python commands will now come from the default Anaconda environment in $HOME/anaconda, which is itself a kind of a virtual environment. You can create sub-environments with e.g. conda create -n myenv1 ipython scipy, but this is not necessary.
As a side note, you can also use pip (also in $HOME/anaconda/bin) to install PyPI packages into your Anaconda default environment (it has pip installed by default) or any of the sub-environments (in which case you should first install pip into the sub-environment using conda install -n myenv1 pip).
It is possible to install parts of Anaconda manually into an existing virtualenv, but using their installer is by far the easiest way to test and use, without affecting any of your existing Python installations.
When you create your virtualenv use the -p flag to give it the path to the Python executable you want to use:
virtualenv -p /path/to/python-anaconda-version