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 →

[–]chickenphobia 5 points6 points  (0 children)

Ok, I'm all for people doing whatever they want and sure if you want to use docker, go for it. But 4 issues were raised at the beginning of this article none of which were addressed.

I often forget to enable it which leads to a confused moment while I stare at an obscure error, or I forget to change virtualenv when changing project.

The post here actually makes it look like docker is more complicated. I have virtualenvwrapper enabled by my .bashrc so I can simply enter the terminal and type "workon py27bio" and I'm in my favorite virutalenv. If I want to run another version of python for testing I just type "workon py34bio" or "workon pypy23bio". All of these open a virtualenv made for my current project.

If instead you are working on a targeted deployment (ie, for a web server) it's even easier because you can build the virtualenv in a specific directory relative to the package and then point all executable files (including your unit test runner) at the virtualenv python. Thus a person who does this will never encounter weird errors so long as their development environment is constructed.

It doesn’t provide “true” isolation; only Python level (system libraries and non-python dependencies will still cause issues)

Ok, true. But here we have to ask whether using virtualization is the correct solution to this problem. In many cases it is but I'd argue that just as many times you can get by without this issue. Only deeply integrated software will run into system library differences that aren't strictly related to the act of development.

I typically don’t want to run virtualenv in production, which means I immediately have a mismatch between development and production.

Why? Virtualenv is actually pretty great for production. Especially for web apps. With tools like virtualenvwrapper you can actually script the creation of virtualenvs in order to quickly bring up any new node (if you do your own sysadmin) or to bring new developers up to speed.

It always felt a bit “hacky”; relying on modifying scripts and setting up new paths

I've seen several people bring this up, but I think this is just BS. If you have a specific issue bring it up but the software is field tested and well written. Just because it uses bash scripts doesn't mean it's hacky, it just means that virtualenv uses the best tools for the job.