Issues

Issue #230 wontfix

Proposing env. variable WORKON_AUTOCD

Tobias Herp
created an issue

While auto-changing the directory to a new virtualenv after creation can be annoying (ticket #220), I almost always want to change directory when activating an env by workon. This could be customized by an environment variable.

I propose a variable WORKON_AUTOCD and the following values:

0 - don't change directory automatically

1 - change to the root of the newly-activated environment

2 - if currently working in a virtualenv, try to change to a corresponding directory in the given env; for example, when working in ~/.envs/foo/some/sub/dir and issueing workon bar, try to change to ~/.envs/bar/some/sub/dir, and to ~/.envs/bar if it doesn't exist.

3 - like 2, but try every parent before falling back to the root of the new environment (i.e. ~/.envs/bar/some/sub, then ~/.envs/bar/some, finally ~/.envs/bar). This would be useful when working in closely related envs.

Yes, there is cdvirtualenv, but this is painful when not supported by a good tab completion feature; this is present in bash, but for example not on Windows. Even with tab completion, I'm happy for every command I don't need to issue.

For a start, it would be sufficient to implement "0" and "1".

Comments (7)

  1. Tobias Herp reporter

    After some reading, I suppose the described functionality could be realized by $VIRTUALENVWRAPPER_HOOK_DIR/predeactivate and $VIRTUALENVWRAPPER_HOOK_DIR/postactivate hooks. Or did you mean something else?

    Thus, my proposal is to provide the functionality by such default hookscripts ;-) IMO, it should be available very easily, without the need to install another package of any kind. Of course it would be possible to create virtualenvwrapper-hooks and virtualenvwrapper-hooks-win packages (and I might do so), but I consider it a good idea to have a simple environment variable which adjusts this behaviour.

  2. Doug Hellmann repo owner

    If you run "setvirtualenvproject" with a virtualenv active, it will configure that virtualenv so the next time you activate it with workon you are placed back in the directory where you ran setvirtualenvproject.

  3. Tobias Herp reporter

    Ah ok. So this defines the "entry point" for the virtualenv.

    The downside of the current solution is that there is no default entry point (the root of the virtualenv), so it must be run for each virtualenv. Someone unaware of this command possibly never will discover this.

    So I update my proposal:

    0 - current behaviour

    1 - current behaviour; default entry point is the root of the virtualenv (I'd like this to be the new default)

    2, 3 - like described above.

    Or simply change the workon command to always work like the 1 choice, and leave the rest (2 and 3, and the variable) to hook scripts.

  4. Doug Hellmann repo owner

    The mkproject command creates a directory and sets up the auto-cd behavior. One could easily use a postmkvirtualenv hook to set the directory to a specific directory (option 1 or 2). Option 3 does seem like a more flexible way to do it, but it's also less predictable so I'm not sure whether it's a good idea.

  5. Tobias Herp reporter

    "One could easily use a hook" - this sounds very complicated for something which should be a default behaviour. I can't think of a good reason for not changing to the project root by default when using workon. I just tried to be polite and assume there might be a reason, so I proposed an environment variable.

    The setvirtualenvproject command is a poor solution IMO, since ...

    • it is hard to remember (there is no easy to find help which points to it)
    • the name doesn't tell well enough what the command does
    • it must be issued for every env
    • for the Windows adaption (which should mimic the original virtualenvwrapper as closely as possible), it is extremely inconvenient, because of the lack of a good command completion feature (the Windows shell expands only names in the current working or given directory).
  6. Log in to comment