https://pantsbuild.org/ logo
#development
Title
# development
h

hundreds-father-404

08/19/2019, 4:09 AM
Has anyone looked into adding passthrough argument support to V2 goals? It’ll be even more useful now that integration tests are running with V2. I tried to add it today and didn’t get far
a

aloof-angle-91616

08/19/2019, 6:14 PM
i remember explicitly leaving it as a TODO in my head
how did you try to add it?
w

witty-crayon-22786

08/19/2019, 8:09 PM
they're going to be... interesting... from an API perspective.
a

aloof-angle-91616

08/19/2019, 8:10 PM
passthrough args are parsed at bootstrap time and can therefore probably be provided as a singleton at engine creation
w

witty-crayon-22786

08/19/2019, 8:11 PM
could try putting them on the v2
Goal.Options
class somehow...? i don't fully understand their semantics in v1... i think that it was something like "all goals that support passthrough args can consume the global passthrough args"... and so if you ran multiple goals (or multiple tasks that consumed passthrough args), they might end up consuming passthrough args intended for another task
a

aloof-angle-91616

08/19/2019, 8:12 PM
i believe so
but i don’t think that’s a v1 semantics problem i see it as a UI problem with passthrough args in general
w

witty-crayon-22786

08/19/2019, 8:13 PM
... but. hm, yea. what you said about making them a singleton (or a RootRule param) makes sense.
doesn't get you a defense against the "i'm running both JVM and python tests" case, but... this is mostly supposed to be a convenience.
a

aloof-angle-91616

08/19/2019, 8:14 PM
i would like to make it easier for a task to use an
--args
to automatically declare support for and add any passthrough args to the tasks args option, because that’s always been an annoying and confusing bit of boilerplate
that way anyone knows they can change a task’s specific args with a reliably named option
and i think i am giving up on trying to find a better way to interpret passthrough args than just applying them to every task
w

witty-crayon-22786

08/19/2019, 8:16 PM
@hundreds-father-404: ftr though: in v1, passthrough args are sugar on top of passing args to the
test.pytest
task. so, without that sugar, the equivalent in v2 would be to consume them from a subsystem
a

aloof-angle-91616

08/19/2019, 8:16 PM
but having the reliably named and scoped option for any task which has arguments to change i think should reduce the need on the user’s side for passthrough args
each task has to implement getting the passthrough args manually and adding them to other args (e.g. pytest)
(also, we can then add compiler option sets on top of that to any task also for free. no rush to do that now though)
i think that’d be a huge win though
(just a win for me personally)
w

witty-crayon-22786

08/19/2019, 8:59 PM
re: https://pantsbuild.slack.com/archives/C0D7TNJHL/p1566245638103100?thread_ts=1566187754.088500&cid=C0D7TNJHL i think that maybe what this particular suggestion would look like instead would be exposing a type representing the PassthroughArgs here: https://github.com/pantsbuild/pants/blob/master/src/python/pants/engine/legacy/options_parsing.py ... which would mean that a
@rule
could request them
there are potentially other implementations related to tying passthrough args to Subsystems somehow. but would need more design.
a

aloof-angle-91616

08/19/2019, 9:32 PM
ok, but i think it would be great if a rule could request “command line arguments” in general (which would be the concatenation of an args option for that rule specifically + passthrough args) and i think we have a chance now that we’re rewriting this to streamline that experience of (1) a task declaring an args option and (2) a user passing args to the task on the cli
that experience doesn’t need to be tied to any specific implementation
w

witty-crayon-22786

08/19/2019, 9:39 PM
You can already request "command line arguments" via subsystems though
a

aloof-angle-91616

08/19/2019, 9:39 PM
yes but the user has absolutely no clue which option to use to add arguments
w

witty-crayon-22786

08/19/2019, 9:49 PM
ok. are you suggesting https://pantsbuild.slack.com/archives/C0D7TNJHL/p1566248429112000?thread_ts=1566187754.088500&cid=C0D7TNJHL then? i don't have a great idea of what this would look like, so if you do, explaining it on a ticket would be good.
i'm not sure this is a blocking issue for Eric though, so probably not urgent in any case
h

hundreds-father-404

08/19/2019, 10:30 PM
No this isn’t blocking. Only an important UI change as we start to roll out V2 execution of integration tests. Would be good to do sooner than later
a

aloof-angle-91616

08/20/2019, 4:20 PM
that's correct, it's not blocking, but since we're redesigning how passthrough options work, we have a chance to allow for the kind of options user interface i've been describing, and i would love to have in mind the idea of a more unified trailing args when designing this so that we can backwards-compatibly begin to do that later
👍 1