I've just installed virtualenv and virtualenvwrapper on my computer. Now I want to use it to work with Django. When I run mkvirtualenv django, from ~, the interpreter stays there. Does that mean I can create my django files there? Or is the environment not that virtual? Should I create my own folder instead where I work on the project? I thought mkvirtualenv would create one for me automatically and take me there upon running workon, otherwise, what's the point of even using virtualenvwrapper?
EDIT: These few lines from my .bash_profile might help you:
export WORKON_HOME=$HOME/.virtualenvs
export PROJECT_HOME=$HOME/Devel
source /usr/local/bin/virtualenvwrapper.sh
virtualenwrapper will create the virtualenv in your ~$WORKON_HOME/ directory. This is the venv only and is distinct from any associated "project" directory you might (or not...) want to use and which virtualenvwrapper will indeed not create.
IOW, at this point you are exactly in the same directory as when you ran the mkvirtualenv command.
If you want to associate this venv to a project directory, you have to create this directory (if it does not exist yet), and then - with your venv activated - run setvirtualenvproject /path/to/your/projectdir (or cd /path/to/your/projectdir and here run setvirtualenvproject without argument).
Once done with this, next time you activate your venv with workon myenv, you will be automagically cd'ed to your project directory too, and the cdproject command will bring you back there if you cd elsewhere.
As for other reasons to use (or not) virtualenwrapper, you can read the doc and find out by yourself what other features it adds to the raw virtualenv and whether you want those features or not.
FWIW the behaviour you expected (creating both the venv AND the project dir) is given by the mkproject command
The main advantage of virtualenvwrapper is the separation of your environment from a specific working directory. Just activate your environment with:
workon django
The prompt should change to:
(django)
Now you are free to work from any directory you want.
Related
Before I install virtualenvwrapper, I have some virtualenv installed in different location. Is there any way to collect them in virtualenvwrapper so that appear in workon command?
Yes, that should be possible.
Virtualenvwrapper allows you to custom define where your created environments will be stored:
export WORKON_HOME=/path/to/your/envs
If you point this to the location of your virtual environments from virtualenv, it should work.
You should add this line to your .bashrc or .zshrc or whichever else shell you're using.
The problem with this is that you wont be able to activate any environments that are not in that folder.
In that case it will probably work to just copy the whole virtualenv into where your virtualenvwrapper environments are created.
You can find out where that is like this:
mkvirtualenv test
workon test
which python
# Will print path to virtual python interpreter:
/path/to/virtualenvs/test/bin/python
Copy the desired environments so they are in the same folder
as the just created test environment. Here, this folder would be
/path/to/virtualenvs/. I'll call it $VENVS from now on.
After copying it should be something like /path/to/virtualenvs/my-other_env1, /path/to/virtualenvs/my-other_env2.
Assuming you created my-other_env1 and 2 before with virtualenv with default settings, copying my-other-evn1 can be done like:
cp ~/.virtualenvs/my-other-env1 $VENVS/
You can delete the test environment afterwards using
rmvirtualenv test
(Of course, if you already know what that folder is, it's not necessary to create the test environment.)
complete beginner here. Trying to build a flask web app. Using Windows 8.
Having some problems activating my python virtualenv in Cygwin. I have been using git shell up till now with no problems.
I copied my folder ("app") into my cygwin home directory and it is set up like so:
app - templates
- static
- flask - env - scripts - python
- ...
- hello.py
- ...
I change directory into the app folder, then when I type the command to activate my virtualenv:
$ source flask/env/scripts/activate
The terminal shows:
(env)
so I assume that it is working, until I double check which python:
$ which python
and that returns my original global python install, not the virtual environment. I've checked the installed packages to double check which python environment I am using.
I use the same command in git shell and it activates the right virtualenv. Where am I going wrong / what do I need to change? Please let me know if you need any more information.
I created a new virtual environment using cygwin and when I activated the new env, it switched to that environment fine. Why won't it work for the folder which I copied in?
I created a new virtual environment using cygwin and when I activated the new env, it switched to that environment fine. Why won't it work for the folder which I copied in?
This last sentence is the real problem. The way you try to activate is correct. The problem is that the virtualenv directory must not be moved.
The activate script inside the virtualenv uses absolute paths internally. If you move the directory, the paths will no longer work, and so which python finds the first valid binary on PATH, which is your global binary.
If you need to move the project to a different location, and the virtualenv together with it, then recreate the virtualenv, do not copy it.
The recommended practice is to have a requirements.txt file, and install packages using pip install -r requirements.txt.
That way, recreating a virtualenv is very easy: create an empty virtualenv, and run the pip ... command. There should be nothing else inside the virtualenv that needs moving, only what pip put there, or other python installer scripts, if you used any (and which you would need to re-run, in addition to pip).
I'm embracing VirtualEnvWrapper - and like what I see a lot. However as I try to get going I'm not seeing the behaviour I expect when trying to set up project directory association with virtual envs.
I've installed virtualenv and -wrapper. I can create envs and "workon" lists them fine. I can deactivate and rm them happily. So all appears functional. I read the docs regarding project mgmt. (Also a good video tutorial, and the desired proj association behaviour explained at 10:39 )
When I try to associate a work directory with an env, it accepts my cmds fine, but when I "workon" the project, it does not put me into my designated working directory.
e.g. I have a working area ~/Ross_code (and I've set this in my .bashrc as $PROJECT_HOME). In there is an existing project folder ~/Ross_code/superproj
So now I create an env with
mkvirtualenv superp
Then I go to my existing project dir and associate it with the env:
cd ~/Ross_code/superproj
setvirtualenvproject
Setting project for superp to /Users/ross/Ross_code/superproj
Then I exited the virtual env with "deactivate" and reactivated with
workon superp
But the present working dir remains my ~/ folder.
I checked the .project file which seems to have been set properly by the call to setvirtualenvproject:
cdvirtualenv
more .project
/Users/ross/Ross_Code/superproj
but calling "workon" never sticks me into the expected spot. I thought maybe the env and the project directory needed to be of the same name, but that didn't make any difference either.
Any idea why that very attractive project association capability doesn't work for me?
-Ross.
LATER - More info:
I tried to also use the mkproject command, which should create a directory for my code in the $PROJECT_HOME area, and create the virtualenv at the same time and associate them with each other.
Calling
mkproject junkproj
does in fact create the project directory nicely, and sticks me into the virtualenv, and cd's into the junkproj directory. But when I deactivate, and then "workon junkproj" again, I'm still left in my ~/ directory, rather than going into the project directory in $PROJECT_HOME
:(
The problem here is that the newer versions (this hit me upgrading from ubuntu 14.04 to 16.04) of virtualenvwrapper use a slightly different protocol for the setvirtualenvproject parameters:
setvirtualenvproject [virtualenv_path project_path]
In order to make the association you want in any virtual env, be in the project folder and the virtualenv and use:
setvirtualenvproject $VIRTUAL_ENV .
The dot is for the present directory - or you can use the path of the directory you want workon to take you to. Once you do this workon will switch you to the folder you want and cdproject will work as expected.
If you used the old protocol, you'll have a .project file in your project folder - you can move this to the $VIRTUAL_ENV folder rather than invoking the command with the new protocol to make the association. The file just contains the project directory you want to associate with virtualenvwrapper shortcut commands like workon and cdproject.
workon doesn't auto change directory to project or environment directory.
You can do this with the postactivate script - there's a really quick how-to in the second half of the virtualenvwrapper tips and tricks section.
I was given a project to work on and am now trying to run that project in a virtual environment.
I am new to python, but in the past, I was comfortable with the "manage.py runserver" concept. I'm having trouble learning virtual environments.
I know that I have virtualenv installed.
My first direction given to run the virtual environment for this project was to run virtualenv --python=/var/bin/python --clear --no-site-packages --unzip-setuptools --setuptools ~/virtualenvs/project_name
That results in this error:
The executable /var/bin/python (from --python=/var/bin/python) does not exist
I already have python installed, what does this even mean? I am also confused about this syntax, --python=/var/bin/python, was that a relative path that I should have switched out "python=/" for something else? what does the "=/" actually represent?
Am I running the command in the wrong folder? I have tried running it in both the outer project_name folder, containing a subfolder of the same name, and also, inside that subfolder (which contains the manage.py).
However, I can't find the var/bin/... paths anywhere in either folder. Where should the bin paths be located?
Any help or insights would be much appreciated, thanks!
If you are new to virtual environments, these are the steps I would take to install a virtual environment. I hope this helps.
Setuptools
First to check if you already have it installed type the following:
python
>>>import setuptools
If you get another >>> then you have it installed, otherwise you'll get an error. If you happen to blow up setuptools, here's how you reinstall it:
http://pypi.python.org/pypi/setuptools
1.Download Python 2.7 egg
2.Change directory into new unzipped folder
3.Run the following command:
sudo sh ~/folder/you/downloaded/to/setuptools-0.6c11-py2.7.egg
Virtialenvwrapper
sudo pip install virtualenvwrapper
Setup
1.Create your directories
sudo mkdir /project_name
sudo chown -R yourusername:admin /project_name
2.Find virtualenvwrapper.sh to use in step 3 below, check the following paths:
/Library/Frameworks/Python.framework/Versions/2.6/bin/virtualenvwrapper.sh
/usr/local/bin/virtualenvwrapper.sh
3.Update your profile script (~/.bash_profile or ~/.profile) in a text editor, adding the lines below at the bottom of the file. If you don't have either of these files in your home directory, create a file named .bash_profile in your home directory.
export WORKON_HOME=$HOME/.virtualenvs
source /insert/your/path/to/virtualenvwrapper.sh
4.Quit your Terminal app and restart it. You should see a bunch of folders get created when you restart it. This will only happen once.
5.Make your environment
mkvirtualenv django
(django)$ <- now you are in your new virtualenv
6.To leave your environment:
(django)$ deactivate
7.To enter your environment, quit Terminal again to reset paths so we can test our setup and move into your working directory to checkout a project:
workon django
(django)$ <- you are back in your environment
It seems like that python is not installed in /var/bin/python on your machine. The path seems a bit odd, a more common path is /usr/bin/python.
One way to check where python is installed is to run which python. Try to replace /var/bin/python in the command you use when creating the virtualenv with the result from the which command.
#Try this step by step procedure
1. open terminal
pip install virtualenv
2. cd desktop
desktop> virtualenv env
# A folder named env will appear on your desktop
3. desktop > cd env
#now activate the virtualenv
desktop/env>.\Scripts\activate
# now you will see
(env)c:\...\desktop\env>
I'm trying to use virtualenv on my development machine. I successfully created my new environment issuing virtualenv venv in /home/user/. When I try to activate it (from user location) with sudo venv/bin/activate I get venv/bin/activate: command not found.
You don't run activate as a script; you need to source it in your shell, since it affects the shell itself.
It probably also doesn't make any sense to run it under sudo.
Check that the virtualenv is actually where you think:
stat /home/user/venv/bin/activate
If it is, then you need to source the file in:
source /home/user/venv/bin/activate
If the file doesn't exist, you've created the venv in a different location.