Closed brianbruggeman closed 5 years ago
vex is not in the business of processing environment variables. It is in the business of running commands in a virtualenv. Sticking to that business alone is the only way that vex can be simple or convenient. If it is not simple or convenient, it has no purpose of existing.
To do its one purpose, it passes through environment variables. Changing environment variables is a huge ball of wax. I do not want vex to be in the business of editing environment variables, I want it to be transparent as possible. If only because editing environment variables is a bottomless swamp when it comes to debugging the odd issues people contrive in their shell environments. It is important to me that vex is a neutral broker with regard to environments, as much as possible (given the obvious limitations imposed by virtualenv itself)
Once .vexrc is used as a way of conveying environment variables then it will be natural to go "hey, I want all different programs to have different sets of environment variables" and now vexrc contains a ton of sections for different files. Then someone wants a new switch to point to an arbitrary external .env file. And it should support docker's format. And someone else wants it to automatically be picked up in the current directory, but someone else doesn't.
Once all that is in vex, I discard vex and move to a desert island and use shell functions because this is the opposite of why I created vex.
I suppose this is probably a feature request, but I'd like to be able to do something like the following:
Right now, the env section is a direct text replacement, which makes something like the above fairly impossible. I end up polluting my standard environment so I can pull it into my vex environment. That's probably okay for the example above on a system I control completely. It's probably undesirable from a system standpoint where I'd like to keep my venv and other separate.