Does anyone have any comment as to what the solution for this ticket might be? Maybe Yusra AlSayyad, Nate Lust, or Andy Salnikov have opinions as to how to deal with this or whether we should ignore it?

I think setting logging level in the code is a bad practice indeed. Someone has to decide on logging strategy and I'm not sure if we can provide any decision for that. I believe we already have all tools that are needed to implement a reasonable strategy if someone else decides what it is.

One random idea for a strategy - the task could have a flag which defines the logging level for the messages, you could select INFO (or default) if you run it once or DEBUG if you run it many times. If a user want to see messages from latter case then it's easy to change logging level from command line for that particular task (or whole thing).

I very much agree with Andy that setting the logging threshold in the code is a bad practice.

I can empathize with the strong psychological pull to having some default logging from a Task, but rationally it seems to me that if a message should be DEBUG in the run-many-times context, it should still be DEBUG in the run-once context.

What about through config? Seems like this is something that is natural for pex_config.

• Config base class for tasks defines a field that controls the logging for that task
• There is a setting that controls the behavior for all subtasks that fires before the task config log level so you could override just one task
• This allows Pipelines to control longing per label, in the case there is more than one instance of a task running
• Allows individual control for a task if it is both a top level task and a sub task
• log levels would then be stored with configuration (in config files, pipelines, persisted configs etc) and would be repeatable each time a task is run.
• Lets logging for a task (and subtasks) be set at task creation time