signal handling should happen in dep, not gps

[kardianos]

Currently gps handles the signals. This is probably inappropriate for a dep library unless dep is just a shell over the real project.

Cancelation should be handled with context. Any gps method that writes multiple files or hits the network should take a context that can be canceled. Completion of rollback or cancel can be signaled by the called function returning.

[sdboyer]

Cancelation should be handled with context.

So, it would be quite feasible to modify the way that signal handling works to have:

1. make gps.NewSourceManager() take a Context
2. Internally attach its current signal handling logic instead to the context's cancellation/done channel
3. dep registers signal handlers itself, and attaches them to the context it passes into gps.NewSourceManager()

This would be along the lines of suggestions from @bradleyfalzon. At the time, it seemed like a toss-up and I already had it written the other way, so I just stuck with that. Converting it would be just fine, though.

Any gps method that writes multiple files or hits the network should take a context that can be canceled.

Maybe? I'm not sure how much value this really adds, though. At first, I thought it might help with e.g. sdboyer/gps#84, but further reflection makes me worry it might just get in the way.

Concrete use cases/patterns would help.

[kardianos]

If you hit the network, it can/will hang. if you hit the disk, disks can be super slow at times in envs.

Using context can let you create a more robust design. You can have dep start many tasks at once, if there is a long running task you can allow the user to cancel that specific task. It allows you to expose dep and gps as a generic library that could be used from long running services. I could envision a web service or shiny front end that are long lived and provides a nice GUI.

If you build something new for general use, I highly recommend using context rather than making a console short lived cmd assumption.

[sdboyer]

Hmm, yeah, that's certainly the goal. OK - a significant refactor of that subsystem is already needed. We can incorporate explicit context/cancellation control in method signatures as part of it. 👍