move some common-use components to swmain + further discussion

[mileslucas]

Spitballing a couple ideas here, feel free to split into different issues if you like.

I think some of the scaffolding code for setting up the tmux daemons should be upstreamed to software-main (e.g., the cam-*start scripts), that way it can be used for device control daemons. In doing this, I think we should make the scripts python, and perhaps could consider some different CLI approaches.

For example, we could greatly simplify the cam-*start stack with an interface like camstart <cam_name> [<mode>]. This argument parsing is easy in python, and presumably the cameras can be modularized and listed out easily in python.

Thoughts @DasVinch?

[mileslucas]

For the first part, I don't really think there needs to be any new code, right? Just find/create a tmux session based on a configurable name, then send a couple sets of commands, with a unique entrypoint script (the python -im ... part). Perhaps if the "couple sets of commands" part of that is annoying it could be put into a method. If it's something that requires slight customization for each camera, a class with an overrideable hook would be another way.

[DasVinch]

Gonna split into two issues.

1/ tmux components. Agree. But there are already several users using a fork of camstack and relying on this being standalone-ish (albeit already broken since the FG code has moved to a private repo already), so...

The alternative is what we discussed this morning, submodule/subpackage camstack into swmain. Not great, not terrible.

[mileslucas]

eh fair enough. I vote we put the appropriate code in swmain anyways, build new code from that, and when it's time to rip the bandaid off here it can be done then.

[DasVinch]

Well if we go and merge camstack fully into swmain we can mark current camstack to be legacy and the people who want to keep up with camstack in the future clone the entire swmain?

[DasVinch]

No regression in features through the merge but full power to reshuffle files.

[mileslucas]

Yeah but it creates much more overhead inside swmain, like think of all the extra scripts and dependency management that comes with that.

I do support somehow forking camstack so that we don't have to make decisions locked into the current architecture. Perhaps a camera_control repo that contains a slimlined camstack with the common tmux, daemon spawning, etc. code upstreamed into swmain?