All committers have signed the CLA.

I've expanded the approach, where shell now refers to actual shell expressions, for expressions like:

[ 5 -gt 1 ]

or

echo ${MY_ENV} | grep foo

The shell_var now refers to just testing for variables.

python now supports statements (using eval only supports expression, so 1+2>=3 works but not import sys; 1+2>=3). Instead, We can use exec and extract the results (from the last expression) afterwards.

Yes I also partially agree that the use of eval and supprocess tends to be discourage (especially when we are executing unsanitised user input); therefore I did put comments on stating the potential danger within this approach in previous revision.

However, the more I think about it, the more I reckon that the nature of tmuxp or other similar tools like tmuxinator might render these concerns a bit pointless. The fact is, tmuxp will already be executing arbitrary commands based on the given list of shell_command.

From my point of view,

1. The use of subprocess to evaluate shell output shouldn't be of concern, as it's not too different than what tmuxp is designed to do (execute arbitrary commands to setup workspace).
2. My only potential concern is using eval / exec for python statements, for the fact that they are executing inside the python interpreter, and they might change the internal state inside tmuxp (e.g. they can modify some variables within tmuxp).
   • Perhaps this concern can be eliminated by evaluating the python statement inside a subprocess as well (to isolate the effect)? We can probably re-export the environment variable to the subprocess Python to achieve the same effect.

RE:

Can you think of any other software projects that have declarative configurations directly execute code? 1

Aside from the examples that you have given (many of which just execute any commands given without any security measure), my experience with direnv is that it requires user to explicitly opt-in when encountering a new .envrc file.

• However, the main difference is that direnv auto-load files when cd-ing, so it provides user a chance to manually review the file before auto-loading (it hashes the file to monitor changes to .envrc file), so even if they had just cloned some repository online direnv would prompt user before auto-loading it.
• In tmuxp's case, users manually issues a load command, so they should be in-charge of reviewing the file (if it comes from internet; the same pretty goes for any scripts that comes from the internet)?