Add a --wait flag to the flush command to wait for a synchronization cycle to complete about mutagen

[mystor]

I think this might fall along the lines of providing more support for scripting mutagen. Along these lines might also be a flag to mutagen create which causes it to only log the session ID, and a flag to mutagen list which prints a machine-readable format.

[xenoscopic]

I've had similar requests for this before (the flush command), which I've been a little hesitant to implement because I've wanted to keep the CLI interface as minimal as possible, but your reasoning about integrating the flush command into a build script is compelling. Just to be clear: your build wrapper is some script that you're running on your local machine that dispatches commands (via ssh or something) to your remote machine? I.e. it can run mutagen commands that can connect to the local daemon?

In terms of implementation, this isn't too tricky I think. Might be able to push this out with v0.8.x.

I'd also definitely like to see a "plumbing"-style CLI surface for Mutagen. My original vision was that tools would integrate through the daemon's gRPC interface, but unfortunately the gRPC ecosystem is still too nascent to support the necessary IPC transports (Unix Domain Sockets and Windows Named Pipes) for all gRPC implementations, and for scripts this doesn't make sense. Additionally, as Mutagen grows, the daemon's gRPC interface is also not 100% stable, so it'd be nice to provide a scripting mechanism until gRPC flexibility and Mutagen API stability catch up.

[mystor]

I've had similar requests for this before (the flush command), which I've been a little hesitant to implement because I've wanted to keep the CLI interface as minimal as possible, but your reasoning about integrating the flush command into a build script is compelling. Just to be clear: your build wrapper is some script that you're running on your local machine that dispatches commands (via ssh or something) to your remote machine? I.e. it can run mutagen commands that can connect to the local daemon?

Yup, that's how my script works. I have a ControlMaster for the SSH connection to reduce the latency of creating lots of little ssh sessions, and I start my build commands locally and then send the message to the parent.

In terms of implementation, this isn't too tricky I think. Might be able to push this out with v0.8.x.

Yeah, I don't imagine it would be too tricky. I was considering doing it myself, but I wanted to make sure that it was something you'd want.

I'd also definitely like to see a "plumbing"-style CLI surface for Mutagen. My original vision was that tools would integrate through the daemon's gRPC interface, but unfortunately the gRPC ecosystem is still too nascent to support the necessary IPC transports (Unix Domain Sockets and Windows Named Pipes) for all gRPC implementations, and for scripts this doesn't make sense. Additionally, as Mutagen grows, the daemon's gRPC interface is also not 100% stable, so it'd be nice to provide a scripting mechanism until gRPC flexibility and Mutagen API stability catch up.

Yeah. I think that having a command-line scripting API makes sense. Perhaps there could be a set of scripting commands which are not exposed by default in --help, but only when you run scripting --help?

[xenoscopic]

Thanks for the additional info. I think all of that makes sense. I'll be switching to Mutagen full-time on 1st November for at least a few months, so I'll hopefully be able to get around to doing this in the near future.

[xenoscopic]

I've taken the first step on this with v0.8.0 (currently in beta). It adds a flush command that can be used for force a synchronization cycle. It doesn't currently block, though I can imagine adding a --wait flag that makes it wait for a synchronization cycle to complete. As such, I'll retitle this issue for the time being.

[xenoscopic]

I've just pushed up 2edd9bb, which implements a -w/--wait flag for the flush command. When this flag is used, it will cause the command to block until the synchronization cycle(s) triggered by the command is/are complete.

I will ship this in v0.8.0-beta2, and I'll close out this issue once v0.8.0 ships.

[xenoscopic]

This functionality has shipped in v0.8.0. I ended up reversing the default behavior of the flush command in the end, instead making it block by default (for consistency with the pause, resume, and terminate commands) and adding a --skip-wait flag to disable the blocking behavior.