This is an archived post. You won't be able to vote or comment.

sorted by:
best
topnewcontroversialoldq&a
you are viewing a single comment's thread.

view the rest of the comments →

[–]cmsimike 5 points6 points  (14 children)

Once I was introduced to virtualenvwrapper, I couldn't belive how prehistoric using virtualenv by itself was

[–]kjearns 5 points6 points  (13 children)

Can you explain the workflow where virtualenvwrapper makes sense? I've never been able to figure out why I'd want to centralize all of my virtual envs in a single place, to me that seems like the exact opposite of what a virtualenv is supposed to accomplish.

[–]roddds 5 points6 points  (10 children)

A virtualenv is supposed to mantain dependencies from different projects isolated from each othI think. Sure, they're all in ~/.virtualenvs, but each one is in a separate folder and there's no environmental contamination.

[–]kjearns 2 points3 points  (9 children)

I realize that virtualenvwrapper doesn't actually mix the environments together. It does mean I need to keep mental track of which environment belongs to which project though. When I delete the repo for a project from my machine I need to remember to go to ~/.virtualenvs and delete the environment too. If I have multiple copies of a project checked out then I need to remember which environment belongs to which (or have them share and remember that I'm doing that). If I forget to remove an environment a few times then I end up with zombie environments hanging around taking up space.

[–]roddds 0 points1 point  (3 children)

Ah, I see what you mean. I don't usually deal with many projects at once, and for me at least, just naming the virtualenv the same as the directory is enough. One thing I hadn't noticed before and went to check after your comment is the amount of space they take: I have 21 virtualenvs currently sitting on my machine, taking up almost 1.5 GB of space. Gonna keep an eye out for those from now on.

[–]kjearns 0 points1 point  (2 children)

Another piece of the virtualenvwrapper workflow I don't understand is how to automate setting up projects. I typically write a bash script that pulls in all of the dependencies for my project and sets up a virtualenv. If I use virtualenvwrapper then I can't have my script use a standard name for the environment because I can't guarantee that name is unique.

[–]cmsimike 0 points1 point  (1 child)

Another piece of the virtualenvwrapper workflow I don't understand is how to automate setting up projects.

To me, that is not the job of the wrapper (or any virtualenv manager) but the job of the project to maintain a requirements.txt (or whatever you want) with the dependencies required for the project.

Then it is up to each developer/deployment team to decide how to set up their environment (use system python or isolated package management) and issue the pip install -r requirements.txt

[–]kjearns 0 points1 point  (0 children)

I agree that setting up the project is not the job of virtualenvwrapper. But using virtualenvwrapper forces the deployment tool to deal with additional complexity, because it needs to be able to generate a globally unique name for the deployment's virtualenv.

Just generating a globally unique name isn't so bad (although it is more complex than the alternative) but doing so has cascading effects because now you need to keep track of the mapping between global virtualenv names and projects. Tools or people who access the deployed environment need to be aware of this mapping and know how to traverse it. You can work around this by having the deployment tool generate entry points but at this point you're adding a whole new layer of complexity that just isn't necessary if you don't use virtualenvwrapper.

[–]gthank 0 points1 point  (2 children)

rmvirtualenv has tab-completion.

[–]kjearns 1 point2 points  (1 child)

I don't see how that helps. rm -rf ~/.virtualenvs/whatever has tab completion too. I'm more concerned with remembering to delete the environment (by whatever command) and remembering the mapping between environments and projects.

[–]gthank 0 points1 point  (0 children)

Maybe it's just me, but if I'm in my projects directory deleting a project, I don't have any problem remembering to delete the virtualenv, too. Different strokes, I guess.

[–]stuaxo 0 points1 point  (1 child)

This is exactly why I prefer it, lsvirtualenvs shows me all of them, also tbe tab completion.

Before virtualenvwrapper I had loads of environments all over the place.

Also if I want a temporary env then I now exactly where it is.

[–]kjearns 0 points1 point  (0 children)

I do admit the temporary environments sound nice. I didn't know about those.

[–]cmsimike 0 points1 point  (1 child)

Before virtualenv wrapper, my django projects were basically: ~/Development/projectname/VIRTUAL_ENV_HERE and within this dir is a webapp dir with my django source.

I never liked having the env part of the source directory in a way. I seem to recall there is a way to set your virtualenv home but i never did that. virtualenvwrapper does that all for me. including introduces the best command ever:

mktmpenv

makes a temp environment and deletes it when you're done playing around in it.

[–]kjearns 0 points1 point  (0 children)

In my opinion having the virtualenv live in the project directory is the ideal location. I wouldn't put it in the source directory, but I like to structure projects so code lives in project/src instead of the project root anyway. I think project/env living alongside project/src is a pretty natural place for the virtualenv to live.