Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

input? #59

Open
amonks opened this issue Jul 21, 2023 · 6 comments
Open

input? #59

amonks opened this issue Jul 21, 2023 · 6 comments
Labels
idea Maybe we should build something like this? needs thought We have some decisions to make before moving on this.

Comments

@amonks
Copy link
Owner

amonks commented Jul 21, 2023

Tasks can't take any input. Not flags, not stdin, not nothin else besides. One dogfoody use case for this would be a tag-and-release script for Run, which would require specifying a version identifier somehow.

"not run's purview" is a reasonable answer.

"tasks can declare structured inputs, which the UI can handle appropriately" might be a fun answer

@amonks amonks added enhancement New feature or request needs thought We have some decisions to make before moving on this. idea Maybe we should build something like this? and removed enhancement New feature or request labels Jul 21, 2023
@ecshreve
Copy link
Contributor

i've used this tool in the past and found the ability to pass cli args in willy-nilly useful on occasion. hypothetically maybe i want to wrap some npm scripts with run tasks so they can be part of a dependency tree, but maybe i also want to run them individually for whatever reason and pass --verbose along

@amonks
Copy link
Owner Author

amonks commented Jul 21, 2023

I like in that example that the inputs are just flags, that's easy to understand

I'm not sure about just having a single CLI_ARGS variable tho; it seems like you might want more control in systems with a lot of tasks: if you're building up a task set from many task files spread out over a codebase, I don't think you should have to think about all of the tasks and whether they'll respond the right way to your flag

something like --set=task:key:val seems maximally specific,

run dev --set=jsbuild:verbose:true --set=cssbuild:verbose:false

and then

cmd="something --verbose=$verbose"

…but that's a lot to type


my other train of thought here is kind of inspired by terraform "inputs", where a task can declare some inputs, and you can pass them as flags, but also we render a fun interactive form for any missing inputs

@ecshreve
Copy link
Contributor

oh i'm a big fan of that tf-esque idea. love setting defaults and overriding later as needed.

ansible does some interesting things along these lines with variables where you can assign values to variables in a number of places (in a task / play / playbook, at cli, env vars, vars file...) and then at execution time the value is chosen based on a heirarchy, (ie cli args will always override any other assignments, definitions in vars.yml will always be overridden, etc.)

@cgsdev0
Copy link
Contributor

cgsdev0 commented Jul 22, 2023

run dev --set=jsbuild:verbose:true --set=cssbuild:verbose:false

i think this might not be the best solution, since some programs use different (albeit inferior) styles of flags (go programs come to mind)

separately but also related to inputs, i would love to be able to set environment variables for tasks

@amonks
Copy link
Owner Author

amonks commented Jul 22, 2023

@cgsdev0 ah, sorry, I wasn't clear; I was thinking of combining that with template in the cmd

id = "jsbuild"
cmd = "do-something {{ if verbose == "true" }}--verbose{{ end }}"
run dev --set=jsbuild:verbose:true

env is a great idea and shippable; all for it; created #69 (nice)

@amonks
Copy link
Owner Author

amonks commented Jul 22, 2023

probably more than half of my "cmd"s are multiline scripts, so I don't think a solution without some kind of explicit templating is viable

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
idea Maybe we should build something like this? needs thought We have some decisions to make before moving on this.
Projects
None yet
Development

No branches or pull requests

3 participants