[sashahart]

This is based on my personal experience with tools for using virtualenv.

virtualenvwrapper is very powerful with all kinds of hooks but I just never used all that power and needed things like speed more. virtualenvwrapper provided a lazy loader but that would have various problems from time to time as you'll see on the issue tracker.

So then for a long time I just ran 'virtualenv' and source wherever/bin/activate and found that I really didn't miss virtualenvwrapper all that much, which was a surprise because everyone finds 'workon' invaluable, a position I do understand.

Later my wife taught herself virtualenv and then wrote like 5 lines of shell to do the same thing as virtualenvwrapper (the classic environment-modifying thing) which I found hilarious, and I wrote a version of that in zsh with a little more error checking to make me happy and just jammed it in my dotfiles. Then after some months of using that I decided this is nice enough to publish so I worked on rewriting it as portable shell functions with more error checking and was going to put it on PyPI.

Toward the end of writing that I was feeling pretty finished, when some last detail that I forget made me hacked off about modifying the current shell environment, so on a lark I wrote a prototype of the new idea of only modifying a spawned process's environment in about an hour (most of which was learning further about portable shell) and once it was working I looked at implementing more error checking for all the weird conditions that may arise in shell and I said, you know what, I have no reason not to do this in Python and totally cut the dependency on which shell is being used, who is going to use this without Python anyway?

Then I ended up figuring out how to do prompts and completion and pretty much had a publishable project, which was surprising.

It's still faster to directly run the virtualenv's Python or to use your own small shell function but while YMMV, for my uses virtualenvwrapper is a lot of code I will never use and I use vex every day.

Highlights of my todos: pydoc still doesn't work (the reasons for this are lame) and probably it will be nice to implement --make/--remove to substitute mkvirtualenv/rmvirtualenv (which would also let me dump a pydoc script in virtualenv's bin/ or Script\ dir to fix that problem...)

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

[goblin89]

Well, I use the postactivate hook to set environment variables (for convenience) and connect to project-specific tmux session.

    export PROJECT=`cat $VIRTUAL_ENV/.project`
    export SRC=$PROJECT/src

    [ -z $TMUX ] && cdproject && envopen

Where envopen is my own script that launches tmux (basically tmux -f $TMUXCONF -L $ENVNAME attach -t $ENVNAME with a few checks).

This solution has a lot of flaws, though: it isn't robust and doesn't make sense for non-Python-based projects (my work is not limited to Django). In fact, I'm working on switching to dedicated VMs for my projects—looking for a nice solution currently. I suspect it may involve Vagrant, Docker, perhaps Chef.

[burntsushi]

> pydoc still doesn't work

Are you using `pydoc` on the command line? If so, try pdoc: https://github.com/BurntSushi/pdoc. I wrote it as a tool to replace epydoc (strictly automatic documentation), but it works on the command line just like pydoc. (It can also generate HTML documentation with cross module linking that isn't crap. See an example here: http://pdoc.burntsushi.net/nfldb)

[sashahart]

I do sometimes, more as a matter of muscle memory than volition. I'm going to make a try to use your tool as a replacement for a while and see if I can generate any issues for you :)

However, I still would like to eventually unbreak pydoc for users who might have bad habits like I do.

The issue is that virtualenv itself had an opportunity to fix this (with multiple patches submitted IIRC) and they decided to punt by implementing it as yet another shell function. So for me to unpunt without coupling to the shell, I pretty much have to dump a script into bin/. I guess maybe not that many people use pydoc anyway?

[burntsushi]

> I guess maybe not that many people use pydoc anyway?

That would be my guess. IMO, pydoc isn't very discriminating with what it produces. The HTML is pretty ugly and the command line version just kind of vomits everything in the module to stdout. My idea with pdoc was to try and discover a module's public interface, and then display that.