[runiq]

> everyone finds 'workon' invaluable, a position I do understand.

At first I wanted to praise virtualfish [1] and its ability to automatically activate a virtualenv when I cd into it, but then I realized that vex's way does indeed make more sense. What do we do in a virtualenv? We basically just run pip to do various things, or run the program (in case it's an application and not a library) or test suite.

So yeah, I think I'm gonna switch. The added portability is a nice bonus.

[1] https://github.com/adambrenecki/virtualfish

[StavrosK]

Am I the only one who activates the virtualenv by hand? I don't understand what workon and other things provide. These days, I just have a single virtualenv that gets sourced when my shell starts up, all my projects run in virtual machines (I mostly work with Django). Projects that conflict with others get their own virtualenv, but sourcing it once at the start of the day is still not that much hassle.

[sashahart]

You aren't, I do it all the time. But it does get slightly tedious to type out the whole path. (when switching virtualenvs frequently, unlike your use case)

What I use that is analogous to your single virtualenv sourced at shell startup, is pip install --user. I tend to use that for command line tools like style checkers.

[sashahart]

Awesome, thank you for trying this. Please make a github issue or email me if you have any suggestions informed by the experience :)

edit: That one feature reminded me of Kenneth Reitz's autoenv (https://github.com/kennethreitz/autoenv).

I can't do anything to futz with cd, but it could be possible to reverse that and cd to a project directory when a virtualenv is activated, I am just not sure yet mechanically the right way to choose which one. Worth considering.