pyinvoke / invoke

Pythonic task management & command execution.
http://pyinvoke.org
BSD 2-Clause "Simplified" License
4.41k stars 368 forks source link

Add Verbosity option for CLI- interface #422

Open ibeex opened 7 years ago

ibeex commented 7 years ago

I was looking in documentation and cant seem to find option for verbosity, for example invoke deploy -vvv as usually used for output verbosity/debugging

bitprophet commented 7 years ago

What, exactly, would you expect this to do? :) verbosity for Invoke's internals, your own task code, both, other?

Right now, Invoke's internals have a naive "on or off" debug setting (INVOKE_DEBUG=1 <command>, or inv -d) and we intend to break that up a bit into more traditional log levels sometime (#15).

At present there's no concept of verbosity or debugginess for your own code, outside of ability to hide/show stdout/err from shell commands. We usually try to leave that up to the user, though once we use "real" logging, I'd expect us to expose that to users if they want to use it.

ibeex commented 7 years ago

I was thinking about task code. something like http://click.pocoo.org/6/options/#counting

Aiky30 commented 7 years ago

I would like to add that I couldn't understand why tasks are completed silently in the CLI when compared to fabric, A little reading of the docs highlighted that Invoke can be used as a library and as such doesn't expect to be run in CLI. I think that seeing what it's doing when its doing it (the echo option doesn't do this) for me was useful in many ways in fabric when used as a local task runner (debugging, peace of mind, knowing there where no undetected errors i.e. ones that don't throw an error).

bitprophet commented 7 years ago

That's definitely still covered under #15, @Aiky30. I don't see it ever being the default behavior but I'd like it to be easy for folks to activate just enough log levels to get data like "executing task X now...running command foo...and command bar...ok moving on to task Y...running command biz...btw it exited 127 but since you said warn=True we're continuing..." etc etc. Currently most of that's there, it's just all lumped under debug.

I'll note that since we default to forwarding all subprocess output, I don't see how you could ever get an "undetected error", certainly not in a way that wouldn't also be hard to detect under Fabric (i.e. a very badly behaved program that prints no stdout/err and also exits 0 on error). Do you have an example of this sort of thing?

Aiky30 commented 7 years ago

@bitprophet I may have been unclear with stating that after a little bit of investigation it made sense that it isn't verbose by default. I agree with that.

I have started to migrate my local deployment scripts over to Invoke and started with basic creating folders, assigning permissions, a git pull, and then Django management commands. The script was completing but hadn't pulled and then subsequently couldn't run the migration commands. This didn't output anything and because I was unable to see what was happening I had no idea where it was failing silently.

This is the behaviour I was looking for: "executing task X now...running command foo...and command bar...ok moving on to task Y...running command biz...btw it exited 127 but since you said warn=True we're continuing..."

I shall investigate the debug option and see what's going on and feedback if necessary. I have read through the docs and I don't think I saw any mention of the debug flag. A quick look through the change log sees it mentioned a few times.