Issues

Issue #97 resolved

Tab completion fails in zsh if $WORKON_HOME not explicitly set

Dan Callahan
created an issue

I'm pretty happy keeping my virtualenvs in ~/.virtualenvs, which is the default assigned by virtualenvwrapper_derive_workon_home if $WORKON_HOME was not explicitly set elsewhere.

Unfortunately, virtualenvwrapper_derive_workon_home is called by virtualenvwrapper_initialize, which is called //after// completion gets set up on [[https://bitbucket.org/dhellmann/virtualenvwrapper/src/c847d8f5e53f/virtualenvwrapper.sh#cl-447|line 447]].

This fails because generating completion options calls virtualenvwrapper_show_workon_options, which in turn [[https://bitbucket.org/dhellmann/virtualenvwrapper/src/c847d8f5e53f/virtualenvwrapper.sh#cl-280|relies on $WORKON_HOME having a value]].

Since I'm happy with the default provided by virtualenvwrapper_derive_workon_home, I don't export $WORKON_HOME in my shell initialization files. Thus, virtualenvwrapper_show_workon_options ends up calling cd without any arguments, which causes it to search the root of my home directory for virtualenvs.

In effect, not exporting $WORKON_HOME is tantamount to setting it to $HOME for purposes of tab completion, and ~/.virtualenvs for all other purposes.

Comments (6)

  1. Dan Callahan reporter

    I should note that moving the tab completion block (line 416 to line 448) to the end of the file, after the call to virtualenvwrapper_initialize, resolves this issue.

    Though now that I think about it, in zsh, the tab completion options are being established only once: at shell startup. This means that tab completion options won't be updated to reflect virtualenvs that have been created or destroyed after the shell's initialization. I doubt that's the intended behavior. Unfortunately, I don't know much about zsh, so I can't offer a patch. Yet.

  2. Jeff Forcier

    I'd like to note that I ran into some really bizarre freezing problems in zsh (4.3.12 from homebrew on OS X 10.6) which I traced down to the original zsh completion code in virtualenvwrapper. Symptom was that randomly (maybe 50% of the time), a new shell would simply lock up and never present a prompt. Oddly enough this wasn't a problem on another nearly-identical system.

    Anyway, the commit listed here appears to fix that freezing problem for me (I assume because the completion code is now significantly different), so I wanted to note it here for posterity in case anybody else had a similar issue.

  3. Log in to comment