pantsbuild #development

Channels

welcome

github-notifications

development

rough-minister-58256

06/18/2018, 11:58 PM

rough-minister-58256

06/19/2018, 2:54 AM

going to guess that the best we’ll be able to do with multiple processes is dump each as they finish, followed by the frontend task rendering an aggregated summary

rough-minister-58256

06/19/2018, 2:54 AM

yeah

rough-minister-58256

06/19/2018, 2:54 AM

that seems right to me

rough-minister-58256

06/19/2018, 2:58 AM

and is more inline with my prior thought on 4769 - inner, complete products for e.g.

@rule(PytestResults, ...)

that conducts a full pytest run (and not be allowed to emit any output of its own) and the

@console_rule

would be responsible for getting those and emitting output + summarizing aggregates.

rough-minister-58256

06/19/2018, 2:58 AM

then we could potentially nest

@console_rule

for cases of e.g. weaving pytest + junit + rust + whatever test runners

rough-minister-58256

06/19/2018, 3:00 AM

that leaves/blocks interactivity

rough-minister-58256

06/19/2018, 3:02 AM

e.g.

py.test tests -vvs --pdb

that drops you into pdb - I think that’s a special “mode” of running maybe?

./pants --interactive test /x/y/z:test

that somehow routes you to an interactive mode

@console_rule

that can invoke the pytest runner rule more directly, without caching

rough-minister-58256

06/19/2018, 3:05 AM

probably some interesting ways to wire that up

rough-minister-58256

06/19/2018, 3:07 AM

so I think with remoting in the bigger picture, we don’t want

@rule

to render output (unless invoked interactively, which is maybe another impl variant?)

rough-minister-58256

06/19/2018, 3:08 AM

or..

Trait

witty-crayon-22786

06/19/2018, 3:10 AM

so, i think that @rules are going to render log output, and that that's sortof unavoidable

rough-minister-58256

06/19/2018, 3:10 AM

why

witty-crayon-22786

06/19/2018, 3:11 AM

because of things like compilation

witty-crayon-22786

06/19/2018, 3:11 AM

and tests, and etc

rough-minister-58256

06/19/2018, 3:11 AM

so we’d collect that in e.g.

PytestResults.logs

witty-crayon-22786

06/19/2018, 3:11 AM

you may not have streaming output for tests

rough-minister-58256

06/19/2018, 3:11 AM

and then log that in the

@console_rule

I think?

witty-crayon-22786

06/19/2018, 3:11 AM

but that doesn't mean you don't want to render something as tests complete

rough-minister-58256

06/19/2018, 3:12 AM

well, I think this is maybe where we lean into the “granular targets are better for you” model

witty-crayon-22786

06/19/2018, 3:12 AM

sure, but i think that's the "aggregated summary" bit.

rough-minister-58256

06/19/2018, 3:12 AM

and use target granularity as the carrot there?

rough-minister-58256

06/19/2018, 3:12 AM

also some potential auto-sharding strategies I think

witty-crayon-22786

06/19/2018, 3:12 AM

that only works if rules can log things

rough-minister-58256

06/19/2018, 3:13 AM

they can log things after their entier target has completed executing

rough-minister-58256

06/19/2018, 3:13 AM

(unless they specify --interactive)

rough-minister-58256

06/19/2018, 3:13 AM

so for tight dev cycles, always passing --interactive

rough-minister-58256

06/19/2018, 3:13 AM

this would be how a thing in a remote worker would have to log as well

rough-minister-58256

06/19/2018, 3:14 AM

so starting with full parity there - w/ an escape hatch, I think is a net design win?

rough-minister-58256

06/19/2018, 3:15 AM

then smaller targets (think: inferrence, etc) complete in faster units == 🥕