Pass variable number of extra arguments to dependent tasks

[SimeonStoykovQC]

Problem description

Currently, if I have a task such as

[tasks]
test = 'pytest .'

I can conveniently pass variable number of extra arguments without more configuration, e.g., pixi run test -k "my_new_feature".

It would be super nice to have this opportunity with dependent tasks as well; imagine, for example:

[tasks]
test-c1 = 'pytest ./component1'
test-c2 = 'pytest ./component2'

[tasks.test-all]
depends-on = [
  { task = "test-c1" },
  { task = "test-c2" },
]

... it would be great to be able to run pixi run test-all -k "my_new_feature" here too. I know I can define arguments and reuse them, but it is more tedious, and they do not cover the scenario with variable number of arguments.

Let me know if I have missed any existing functionality. Thank you for developing and supporting pixi!

[lucascolley]

x-ref gh-4208, gh-4280. I'm not sure about making this possible without task args, but feel free to share ideas if you think you have a design that works!

With task args, I think you could do pixi run test-all '-k "my_new_feature"' and have a single arg passed to dependent tasks? I do think we want some way to do this without quoting, though.

[SimeonStoykovQC]

Thanks for the pointers. Feel free to close this issue if it is covered by those.

The passhtrough idea with -- in #4208 is 90% there for me (pixi run test-all -- -k 'new_feature'). The part I am not sure about is that for simple tasks, pixi would pass through the arguments without --, but we need it for dependencies. From my perspective, something like a configurable pass-args-to-dependent-tasks parameter:

[tasks]
test-c1 = 'pytest ./component1'
test-c2 = 'pytest ./component2'

[tasks.test-all]
depends-on = [
  { task = "test-c1" },
  { task = "test-c2" },
]
pass-args-to-dependent-tasks = true  # new feature request, name is provisional

... would make the most sense. However, I cannot judge how well it fits with the rest of the functionality.

[lucascolley]

that does sound like a pretty good idea to me! We need to check that it still makes sense in combination with other proposed changes.

Let's leave this open and revisit it after developments elsewhere, but further design input is welcome!

[jlumpe]

This would be very helpful for things like running pytest for multiple Python versions in a CI job, where I want to restrict what gets run with -m.