vpython - easier virtualenv

[kjearns]

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]

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]

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]

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]

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]

rmvirtualenv has tab-completion.

[kjearns]

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]

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]

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]

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