I think it's important to consider why the loop logger was implemented: we were having a lot of spam on screen even with 50 stacks that weren't getting updated.

That said, I think there are other ways to fix this, while just using a plain logger like we have here. The biggest being: don't show any messages unless a change is happening. So if a status would be "skipped" for any reason, we don't even show that we're submitting it in the usual usage. We could make --verbose more granular - a single -v shows every stack that it processes, but doesn't go into DEBUG logging, and two -vv does the current DEBUG logging. Or, if we're worried about mucking with an existing flag's functionality, we could have separate flag.

I think that'd fix the original issue (we have 300 stacks now? even the loop logger is useless at this point) and still give people the level of visibility they need.

That sounds pretty good to me. I think there's a possibility that it could create confusion if we display nothing for skipped stacks by default. In general, most updates maybe touch 1-2 stacks, so (at least on something as big as our stack config), you'd see no output for a while and might feel like stacker is doing nothing.

That may not really be a problem once the graph walk has ben parallelized though.

Yeah - I was wondering if that'd lead to confusion too, and was sort of why it wasn't the default behavior before. Maybe a small "spinny thing" to show that stacker is running? A modification of this where we can control the animation per tick? https://github.com/harshasrinivas/spinning/