Pass task args to tasks in depends

[rgeraskin]

We can pass arg to task like mise run build arg1. But if build task depends on, for example, lint task, lint task will not get arg1 as arg. It's very handy to have this feature imo.

[jdx]

I don't understand how this could work in a useful way. Maybe you could show me an example.

[rgeraskin]

it's usefull for the tasks that require args. Like

# .mise.toml

[settings]
experimental = true

[tasks.pull]
run = "docker pull"

[tasks.run]
depends = ["pull"]
run = "docker run --rm"

Run:

❯ mise r run ubuntu
[pull] $ docker pull
"docker pull" requires exactly 1 argument.
See 'docker pull --help'.

Usage:  docker pull [OPTIONS] NAME[:TAG|@DIGEST]

Download an image from a registry
mise [pull] exited with code 1

But an invocation of pull directly works:

❯ mise r pull ubuntu
[pull] $ docker pull
Using default tag: latest
latest: Pulling from library/ubuntu
Digest: sha256:562456a05a0dbd62a671c1854868862a4687bf979a96d48ae8e766642cd911e8
Status: Image is up to date for ubuntu:latest
docker.io/library/ubuntu:latest

[jdx]

OK but the second you add an extra dependency to either of these you're sending ubuntu to something that probably shouldn't receive that.

[rgeraskin]

You are right. Maybe it's better to add a new option for task to be able to inherit args?

[jdx]

I think you should just use an environment variable like DOCKER=ubuntu. I don't think it makes sense to propagate args to dependencies.

[rgeraskin]

It's ok to use env variable for single arg. But it's not handy to do it with a changeble number of args =(

I've added -q arg: mise r run -q ubuntu

[jdx]

You're not thinking this through. The second you want to run any param that isn't supported by docker build this would break: mise r run -q ubuntu -w $PWD for example. This might work in a handful of contrived use-cases but that's it.

[jdx]

I will say though that I plan to make the arg functionality in mise tasks vastly more comprehensive in the future and supporting global args is something I'm thinking about.

[jdx]

Also, not that you can do anything about this, I've always felt that docker is a poorly designed CLI and this is a good example. It blows my mind there still isn't (to my knowledge) a simple docker build-and-run command.

[rgeraskin]

yes, and imo it's a responsibility for a mise-user to decide how to set task dependencies. So additional switchers are a way to go.

[tasks.pull]
run = "docker pull"
inherit_args = true

or

[tasks.run]
depends = ["pull"]
run = "docker run —rm"
propagate_args = true

I agree with you about the cli design of docker. But docker is just an example, i'm actually trying to use tasks for terraform cli. But examples with terraform more complicated to show 🙂

[rgeraskin]

Another idea: just propagate shell args like $1, $2, $$@ and so on to the depends task. Because $1 and $2 are accessible only in task that have been called directly from command line for now.

Actually, it provides more opportunities to user to compose run commands with args. And also it's optional to use $1 or $2 in a task.

# .mise.toml

[settings]
experimental = true

[tasks.pull]
run = """
#/bin/bash
docker pull $1
"""

[tasks.run]
depends = ["pull"]
run = """
#/bin/bash
docker run —rm $1
"""

[jdx]

Yeah I like that idea. It'll need to wait until task args get overhauled using my work on usage though. It may end up looking differently though, I may take advantage of templates so you could do it like this:

[tasks.pull]
run = """
#/bin/bash
docker pull {{ args.0 }}
"""

reason being is you could make it work like this alternatively:

[tasks.pull]
run = """
#/bin/bash
docker pull {{ options["docker-image"] }}
"""

which would be called with mise r run --docker-image=ubuntu

[rgeraskin]

Excited to see your updates on task arguments! Thanks in advance for your work)

[eglimi]

This would be a useful feature I'm also looking forward to.

Maybe just can be used as additional inspiration for some aspects. E.g. I like it's explicit argument handling in recipes. E.g.

test target tests="all": (build target)
  ./test --tests {{tests}} {{target}}

This is nice because recipes explicitly define what input they expect and fail otherwise, giving the user a hint how to use it.