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.
Related
I am using MacOS Monterey 12.3.
Once I initialize git for my Python (Python3.9) project, if I set up virtualenv, all of the sudden, git can no longer track any changes made in the given directory.
To see if initializing git and virtualenv in the same directory causes any issue, I first created a directory "directory_above" and ran git init there. Then, I created a sub directory "directory_below" in "directory_above", and I set up virtualenv in the sub directory. Even without activating vurtialnenv in the sub directory, git cannot track any changes made in the directory. git status simply gives me
nothing to commit
As far as I remember, this kind of setup worked fine before, and recently, git started to fail to work with virtualenv.
Has anyone encountered the same issue in the past? If so, how did you solve the issue? I spent some time looking the same issue and solution, but I couldn't find it on here.
it sounds like you ran virtualenv . -- but you probably want virtualenv venv or some other subdirectory
virtualenv writes a .gitignore file which contains the following contents:
$ cat venv/.gitignore
# created by virtualenv automatically
*
that * there will cause all of the contents to be ignored
either delete that file (not recommended) or make your virtualenv in a subdirectory of your project
I'm confused as to where I should put my virtualenvs.
With my first django project, I created the project with the command
django-admin.py startproject djangoproject
I then cd'd into the djangoproject directory and ran the command
virtualenv env
which created the virtual environment directory at the same level as the inner djangoproject directory.
Is this the wrong place in which to create the virtualenv for this particular project?
I'm getting the impression that most people keep all their virtualenvs together in an entirely different directory, e.g. ~/virtualenvs, and then use virtualenvwrapper to switch back and forth between them.
Is there a correct way to do this?
Many people use the virtualenvwrapper tool, which keeps all virtualenvs in the same place (the ~/.virtualenvs directory) and allows shortcuts for creating and keeping them there. For example, you might do:
mkvirtualenv djangoproject
and then later:
workon djangoproject
It's probably a bad idea to keep the virtualenv directory in the project itself, since you don't want to distribute it (it might be specific to your computer or operating system). Instead, keep a requirements.txt file using pip:
pip freeze > requirements.txt
and distribute that. This will allow others using your project to reinstall all the same requirements into their virtualenv with:
pip install -r requirements.txt
Changing the location of the virtualenv directory breaks it
This is one advantage of putting the directory outside of the repository tree, e.g. under ~/.virtualenvs with virutalenvwrapper.
Otherwise, if you keep it in the project tree, moving the project location will break the virtualenv.
See: Renaming a virtualenv folder without breaking it
There is --relocatable but it is known to not be perfect.
Another minor advantage: you don't have to .gitignore it.
The advantages of putting it gitignored in the project tree itself are:
keeps related stuff close together.
you will likely never reuse a given virtualenv across projects, so putting it somewhere else does not give much advantage
This is an annoying design flaw in my opinion. They should implement virutalenv in a way that does not matter where the directory is, as storing in-tree is just simpler and more isolated. Node.js' NPM package manager does it without any problem. And while we are at it: pip should just use local directories by default just like NPM. Having this separate virtualenv layer is wonky. Node.js just have NPM that does it all without extra typing. I can't believe I'm prasing the JavaScript ecosystem on a Python post, but it's true.
The generally accepted place to put them is the same place that the default installation of virtualenvwrapper puts them: ~/.virtualenvs
Related: virtualenvwrapper is an excellent tool that provides shorthands for the common virtualenv commands. http://www.doughellmann.com/projects/virtualenvwrapper/
If you use pyenv install Python, then pyenv-virtualenv will be a best practice. If set .python-version file, it can auto activate or deactivate virtual env when you change work folder. Pyenv-virtualenv also put all virtual env into $HOME/.pyenv/versions folder.
From my personal experience, I would recommend to organize all virtual environments in one single directory. Unless someone has extremely sharp memory and can remember files/folders scattered across file system.
Not a big fan of using other tools just to mange virtual environments. In VSCode if I configure(python.venvPath) directory containing all virtual environments, it can automatically recognize all of them.
For Anaconda installations of Python, the "conda create" command puts it in a directory within the anaconda3 folder by default. Specifically (for Windows):
C:\Users\username\anaconda3\envs
This allows other conda commands to work without specifying the path. One advantage, not noted above, is that putting environments in the project folder allows you to use the same name for all of them (but that is not much of an advantage for me). For more info, see:
https://conda.io/projects/conda/en/latest/user-guide/tasks/manage-environments.html
Should I create a directory in my virtualenv and save the source code for that specific project there?
Thanks in advance
You're not required to have them related in any way. As long as your env is activated, it doesn't matter where it is.
But what's usually easiest is:
Create an empty directory for your project.
Create the virtualenv under that project directory.
Put the source in a src directory under that project directory (or, for really simple projects, just drop it in the project directory).
That way you can check the env settings into version control alongside your code, and if you use an auto-venv tool it'll activate the env every time you cd into the project directory, and so on.
As a side note, if you're just learning this stuff today, you might want to consider learning pipenv instead of using raw virtual environments.
You can save your project anywhere. But you should activate the virtual environment before working on that project.
You can activate the virtual environment using the following command.
source path-to-virtualenvironment/bin/activate
After activating the virtual environment move to your project location.
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.
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.)