https://pantsbuild.org/ logo
Join Slack
Powered by
Has anyone looked into adding passthrough argument...
# development
h
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
i remember explicitly leaving it as a TODO in my head
how did you try to add it?
w
they're going to be... interesting... from an API perspective.
a
passthrough args are parsed at bootstrap time and can therefore probably be provided as a singleton at engine creation
w
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
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
... 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
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
@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
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
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
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
You can already request "command line arguments" via subsystems though
a
yes but the user has absolutely no clue which option to use to add arguments
w
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
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
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
Open in Slack
PreviousNext
Powered by