4 ms·
I'm personally not fond of the virtualenvwrapper porcelain: cd foo; workon foo is an extremely marginal improvement over sourcing the activate file, especially
by lloeki 14y ago
I'm personally not fond of the virtualenvwrapper porcelain: cd foo; workon foo is an extremely marginal improvement over sourcing the activate file, especially when routinely opening and closing terminal tabs and windows.
I use a number of zsh functions and hooks as porcelain to virtualenv so that it behaves like oh-my-zsh bundler support [0] (which I've shamelessly ripped of and tweaked too) i.e being inside foo directory is sufficient. This works especially well since new tabs open straight into the current tab's wd.
[0] https://github.com/robbyrussell/oh-my-zsh/tree/master/plugins/bundler https://github.com/robbyrussell/oh-my-zsh/tree/master/plugin...
- joelhaasnoot 14y agoI've put 'cd foo' in my post-activate hook, saves a command and could ofcourse be widended to do other environment setup tricks...
- xnxn 14y agoYou might want to consider using the virtualenvwrapper.project extension. You define a "projects" dir (which I had already) and then it binds virtualenvs to projects so `workon foo` automatically `cd`s you to the right place. You can also create a new project dir and virtualenv in one shot with `mkproject`.
- timtadh 14y agoI don't use virtualenvwrapper either. I generally have more stuff to initialise for my projects than just the virtualenv. I use swork[1] a tool I wrote for managing your shell environment. It basically dumps all of your environment variables to a file allowing them to be restored later, then it runs a project specific initialisation script. [1] https://github.com/timtadh/swork https://github.com/timtadh/swork