<@U051221NF>: any thoughts on whether <https://git...
# development
@happy-kitchen-89482: any thoughts on whether https://github.com/pantsbuild/pants/blob/454ce5e8140d202ba41787b4cb85b2c22715657e/src/python/pants/task/console_task.py#L25-L28 should become global options? ...my feeling is yes
relates to https://github.com/pantsbuild/pants/pull/6880 ... in v2, all "goals" will be `@console_rule`s, so it feels like individually configuring them would be odd.
on the other hand, it would rule out doing something like
./pants filedeps --output-file=one.txt list --output-file=two.txt $targets
. but i think that i'm ok with that.
Yeah, I think having different goals output to different locations in a single run is a solution looking for a problem
👍 1
thought more about this, and i think that having it global is awkward for other reasons (because many rules will not have line-oriented output, and would thus ignore those settings). so thinking to move it to a scoped subsystem that is optionally consumed while constructing the console.
i might agree about it being a solution looking for a problem, but one general construction that also solves the problem of "i want to do
./pants -q run
, but i also want to see the error if pants fails to build" is discussed in this comment (https://github.com/pantsbuild/pants/issues/7071#issuecomment-456309997)
i want to do
./pants -q run
, but i also want to see the error if pants fails to build
this is currently not really possible in pants (an internal user brought up this use case) because you can't tell pants to output
anywhere different from anywhere else, so this might be a more interesting way to phrase a "problem" with logging output that might deserve a solution
especially since we happen to have the workunit outputs that already buffer and redirect everything
sure. but that is potentially a much more limited case/bugfix. basically: error output should be buffered and dumped on error, regardless of
hm. i have no quarrel with that