Closed pinealan closed 4 years ago
Hey @pinealan!
Initially, Overmind has been creating the sessions on the existing server, but then I noticed that every session inherits env variables of the server. Thus we have to either:
1) use update-environment
option to handle this somehow. (Complex solution, and I'm not sure it will work at all)
2) launch a dedicated server. (Easy and 100% working solution)
@DarthSim thanks for the explanation :)
I understand it's quite painful to make tmux clients/session inherit env vars from the environment which started them, rather than the server
however why would that prevent this option from being added? it's optionally and doesn't affect existing workflow
my guess is the incidental work that comes when the env repercussions have to be explained to un-expecting users?
Well, first of all, I try to keep my projects clean and tidy. As an author and a maintainer, I have some obligations to users. if some niche feature may confuse a common user, I rather not add it.
Next, contrary to popular belief, Overmind wasn't designed as a "tmux manager". Tmux is just a tool that is used for one thing - to allow a user to gain control over processes' STDIN. Using tmux to manage processes within Overmind is pain. It's a very fragile thing, and if a user decides to mess with Overmind's tmux session, they may literally break everything. So I try to minimize ways to change tmux things. If I could deny users to touch Overmind's tmux session or even get rid of tmux, I'd do so without hesitation.
Audience for this are users who already have a tmux oriented workflow with a tmux server running 24/7. This option allows them to add the
overmind
created session into the same tmux server.