--make / --remove

[sashahart]

The protocol for testing this is complicated already and I'm already reasonably happy with how it's working so far, so I've combined --make and --remove into one big branch.

[franciscolourenco]

Is there a reason the option is called --make? Wouldn't --create be more obvious?

[heyLu]

(Regarding your comment in the other issue, but the same applies on this branch.)

Ok, that probably is it: My zsh sets SHELL=/bin/zsh, so both commands work without an argument.

However, SHELL=/bin/zsh vex --remove test doesn't remove anything, SHELL=/bin/true vex --remove test however, does. Is this intended? For the record, even SHELL=/bin/false vex --remove test removes the environment.

The same things happen when I specify the program to use as an argument: vex --remove test /bin/zsh doesn't work, vex --remove /bin/true and vex --remove /bin/false do.

I'm using this branch now. git rev-parse HEAD: c2f3ee83bed72884fbfb2f515fb93f40cd5e239b

[sashahart]

1. --make is shorter
2. It follows the convention set by 'mkvirtualenv' and 'rmvirtualenv' from virtualenvwrapper

otherwise, --make vs. --create is the color of a bikeshed

[sashahart]

heyLu: I also have SHELL=/bin/zsh. Thanks for verifying which commit you are using.

As --remove is an "adverb" to vex's "verb", meaning "tear down when the process is done": Removal does NOT occur until the process launched by vex exits, at which point you will see a message announcing the removal happened. If you run vex and then sit in the new zsh shell without exiting, the removal will not have occurred yet. This is especially easy to do if you do not have a prompt which reflects $VIRTUAL_ENV or $SHLVL.

If you run vex --remove test /bin/true, then /bin/true will exit immediately and therefore remove the env immediately, because vex is not waiting for it to exit and the same for any other command which returns immediately instead of going into a REPL

[sashahart]

The subprocess approach might have to go because Windows makes it all but impossible to run virtualenv by name, since the virtualenv script isn't on %PATH% by default. As far as I know, though, it should be when a virtualenv is activated. So I have this terrible hack which, when we're not apparently in a virtualenv, just tries using sys.executable to locate where virtualenv might be installed.

[heyLu]

Oh well, this is embaressing, I didn't think about that at all. (But pgrep -fl zsh is funny now.)

Works for me, then, as already mentioned. :)

[sashahart]

Don't be embarrassed, you are on the bleeding edge working without docs and you uncovered a major UI issue. Hopefully documenting this carefully in the README will be enough to avoid too much confusion... But your efforts are definitely appreciated.

[franciscolourenco]

Is there a way to just use --remove and not run a command?

[sashahart]

vex runs commands in virtualenvs, that's its job. -r is for cleaning up after running a command.

you could do something like 'vex -r foo true' if you want to.

[franciscolourenco]

Thanks!