Do not enter a shell on every command

[brianbruggeman]

So not to interrupt the workflow that people may be relying upon, but I feel like the following is typical for my workflow...

$ vex -m --python python<Version> <virtualenv name>
(vex:<venv>)$ # do stuff
(vex:<venv>)$ exit
$ vex -r <virtualenv name>
(vex:<venv>)$ exit

It's minor, but I'd like to have the ability to just run, without entering the virtual environment:

$ vex -r <virtualenv name>
<venv destroyed>
$

And I think it might be worthwhile to not necessarily step into the environment every time:

$ vex -m --python python<Version> <virtualenv name>
$ vex <virtual name> <command-line>
$ vex -r <virtualenv name>

So the proposal is to add a new command-line argument: -X or --exit

Functionally, this may mean that the virtual environment is never entered (i.e don't run Popen).

Using my example above:

$ vex -mX --python python<Version> <virtualenv name>
$ vex <virtual name> <command-line>
$ vex -rX <virtualenv name>

[ewjoachim]

You could just do

vex -r <virtualenv name> true

This way, you're running a command that exists immediately and does nothing, so it gets deleted :)

[rsyring]

@brianbruggeman Why don't you put the "-r" on the initial call to vex?

vex -mr --python python\<Version> \<virtualenv name>

[brianbruggeman]

@rsyring I want to clean up old venvs.

[rsyring]

rm -r ~/.virtualenvs/...?

FWIW, I also use rmvirtualenv from: https://virtualenvwrapper.readthedocs.io/en/latest/

Maybe you really want the option in Vex, just thought I'd provide some other options in case it takes a while for this issue to be reviewed.

[sashahart]

Addressing your first example, you can use vex -mr to play in a shell and then clean up afterward. There is no real reason for you to vex -m and then vex -r. If you do not do that, it is not necessary for vex -r name to just remove the virtualenv (which would break backward compatibility, as you know). So if you use vex -mr it is also not necessary to add -X to do vex -rX as a way to avoid breaking backward compatibility. Similarly, if you are using vex -r and supplying a command then it already cleans up after the command, and -X has no meaning, so it is semantically weird to have it there as a separate flag.

The only purpose of vex is to run a command in a virtualenv - in a dedicated subshell rather than munging the current shell environment. I always wanted to keep the interface simple around this single use. So that is why vex some_env some_command uses only positional arguments. The case where you do not supply a command (omitting the second positional argument) is the one where you just want a shell to play in, because that is very convenient, like workon, and conceptually it makes sense: running a shell is running a command and it uses really the same code path, just a slightly different interface for convenience. That functionality is really all I needed to facilitate, and perhaps I should have completely avoided executing virtualenv from vex - to avoid the death of a thousand cuts as every aspect of executing virtualenv became part of vex due to people not just using virtualenv itself when that is what they really wanted. Anyway, the purpose of running vex -m is to make a virtualenv, then run a command, and the purpose of vex -r is to run a command in a virtualenv and then remove it. Both are just decorating the basic operation of running a command in a virtualenv. This never goes beyond the purpose of vex to run a command in a virtualenv.

The only purpose I see for -X is to run -m or -r for side effects and that means you are using vex as a file management utility. I am not motivated enough by that to expand the interface. vex is not designed as a file management utility. There are already tools for that. You have rm and you can use true as the command if you want. If it bothers you, you can create a very simple shell alias to do just that.

The conceptual framework of "I want to remove a directory, so I run a tool for running a command in a virtualenv, and then I omit the command and I omit the virtualenv" is needlessly complex. -m and -r are effectively adverbs applied to the core "run a command" action. -X says you want the adverb, but not the action. I also will not support a flag to use vex to run commands outside a virtualenv, for this same reason. I don't want to suppress the default behavior because that is the behavior I wanted. vex is for running commands, I don't want to make it complicated to understand for people who want to use it to run commands.

So I'm not a fan of -X.