michaelsauter/crane — pull request #69 by bjaglin (2014-07-21 23:51:28+00:00)
Title: Cascading flags

Overview:
* Some refactoring to emphasize when a collection is mutated since this is playing a bit on this
* Added flags to apply commands to a super-set of the given target. I see `-d/--dependents` as a handy way to safely affect dependent containers when doing "destructive operations", and `-D/--dependencies` as a way to easily get one or a set of containers started, no matter where it is/they are in the dependency graph. Combining both allows for targetting the full dependency graph containing the given group/containers (as their might be several independant ones).
* Poor man's solution to https://github.com/michaelsauter/crane/issues/50 (simpler implementation, same benefit as long as the user keeps track of what's running or not)
* (Hopefully) a base for getting https://github.com/michaelsauter/crane/pull/58 right in the future, so that `-s`/`--skip-unchanged` would be safe to use as we could something similar to `-d` internally, within the target group to identify.

Some questions that came to my mind:
* Is it worth giving more granularity for the control of the dependencies (`--linked`/`--volumes-from`) via string variants of these flags rather than booleans? I don't think so - at least I can't foresee any use-case right now.
* Should the new cascading flags care about the state of the "extended" target (exists, runs) ? I think it could be a lot smarter (ignore non-existing containers in `-d` for example), but this would be too much in terms of complexity, both for the user and for the implementation. That can always be done later...
* How does this play out with explicit order defined in the configuration? Good I believe, the implementation should be rather permissive, and should not break if dependencies are missing (which is one use-case for custom ordering I guess). However, these flags only make sense when the dependency graph is well defined, so I see mostly users of implicit ordering using them.
* Would it require some documentation in the README.md? Probably, but I believe the whole dependency stuff would, so I guess this could be done separately in https://github.com/michaelsauter/crane/pull/49

I know you're trying to keep `crane` simple, but I don't think it's particularly complex to maintain - most of the pieces required were in place and a lot of additions are actually tests. What's your opinion? Anyway, this is a first shoot at it!