Hooks on creating/closing session from a repo

[Forsee41]

This one is a feature request.

On some projects I'd like to run certain commands or scripts when entering the 'dev environment'. For example, on python projects I'd like to automatically activate venv. Sometimes I want to spawn dev docker containers, or just spin up databases/cache servers etc. Creating and closing tmux sessions via sessionizer would be a great place to trigger those hooks.

The first thing that comes in mind is to use make rules. You could add something like tms_start_session, tms_close_session, tms_spawn_window to your Makefile as a set of custom rules. If there is a Makefile in a repo, and it contains a corresponding rule, tms could trigger it on spawning session, closing session and creating a new window inside a session.

This might have a big drawback in responsiveness though.

[jrmoulton]

I like the idea. Maybe we could check for a .tms file that's executable? Could be a shell script or python script with a #! Then we could pass some args like session name etc. thoughts?

[jrmoulton]

Shouldn't affect performance in any noticeable way

[Forsee41]

Shouldn't affect performance in any noticeable way

You might want to have stdout of those scripts printed in a terminal, so it should be blocking. Some services might take a bit of time to spin up, that was my concern. For example, if you have docker-compose file that you want to spin up, it could start building/pulling an image if for some reason you don't have it (might have made a local change or just global prune).

A shebang script with a specific name is a good idea, but in that case you should only have 1 that handles all the possible scenarios. Or you could make a .tms dir with several scripts hooked on certain events. The reason I suggested makefile is to reduce an amount of additional files, but on the other hand you can't just add Makefile to gitignore, so all of your local tms hooks are going to end up in your repo. .tms file/dir is better cause you can add it to gitignore. You could pass parameters to the script but I doubt that's of any importance, I don't think those scripts care about how they are triggered.

Also I think that under no circumstances should those files be created automatically on session creation. Only manual creation or explicitly user-initiated file generation.

[jrmoulton]

You might want to have stdout of those scripts printed in a terminal, so it should be blocking.

I think I would actually use tmux to "send-keys" to run the script from the session that was starting. That way it appears in the window that is being switched to

but in that case you should only have 1 that handles all the possible scenarios.

I think this would definitely be the way to go. I wouldn't want to require Make because it isn't always installed everywhere. Using a shebang script means people can just use what they have

Also I think that under no circumstances should those files be created automatically on session creation. Only manual creation or explicitly user-initiated file generation.

I agree

You could pass parameters to the script but I doubt that's of any importance, I don't think those scripts care about how they are triggered.

True. And i suppose they could just run their own commands to find out that info if it was important

So far I think that a user created .tms file is a good option. Simple and would only be run once per window that has a .tms file and shouldn't impact performance in any way that the user isn't in control of

[jrmoulton]

I also have several projects where I want to open sub-folders as new windows. Using local .tms file that could run hooks / open new windows / panes would also be a good thing to add at the same time.

One issue with a local .tms file that I've thought of would be that I probably wouldn't want to commit it to source control but I would want that configuration to just work across machines that have the project checked out. Not sure how to handle that. Maybe committing a .tms file is fine?

[SpyrosRoum]

One issue with a local .tms file that I've thought of would be that I probably wouldn't want to commit it to source control but I would want that configuration to just work across machines that have the project checked out. Not sure how to handle that. Maybe committing a .tms file is fine?

This is an issue when using tms with a project for work, in that case you certainly can't commit the tms file. How about being able to specify scripts in your global tms config for each project?

This would allow, for example, to have in your config file something like

[project]
execute = 'path/to/executable'

So you can have all your scripts in a dir in your tms config, or your ~/.local/bin, and upload them all to a git repo along with your config.