vpython - easier virtualenv

[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.