Add flags and options

[casey]

Recipes should be able to define options:

foo --bar BAZ:
  echo {{BAZ}}

Maybe flags too:

foo --BAZ:
  echo {{BAZ}} # is it "true" or "false"? Or "" or BAZ?

Large changes to the parsing of recipe parameters like this should be considered holistically, along with other possible changes, like $ to support exporting parameters as environment variables, or changing all just variables to being environment variables.

[casey]

It occurs to me that we could use clap to construct recipe argument parsers.

[hustcer]

@casey Will flags be supported ? It's a quite common use case , Thanks !

[hustcer]

flag shorthand can also be supported:
foo --bar(-b):

[sascha-wolf]

Just my two cents: I would already be super happy if I could explicitly refer to the argument's name:

foo bar=something:
	echo {{bar}}

$ just foo bar=stuff
stuff

Of course fully featured flags and options would be lovely but for my personal use-case (and I imagine other's as well) this would already be very helpful, because then I can do things like this:

watch folders='lib,test' cmd='just test':
  find {{ '{' }}{{folders}}{{ '}' }} -name '*.ex*' | entr -dc {{cmd}}

$ just watch cmd='<some other command>'

[colemannerd]

I've just started using Just and my org loves it!

One thing that would improve our usage is opts with enums. We use just to coordinate all of our environment scripts and so we have done things like standardize accounts or environments to a certain list. Right now, they're just strings that we then call a pre-recipe on to check that they are one of a list. It would be awesome if we had this functionality AND incorporaitng an enum for one of the opts. I know #1990 is also similar.

[chosroes]

Any hope for this feature?

[casey]

I'm not currently working on it. It's pretty complex, but it is a good feature.

[alshdavid]

Would definitely love this capability. Right now you can use env vars as named parameters

env profile=release os=linux arch=amd64 just build

But it would be great if the arguments could be first class citizens of just (with default values if omitted) because they are discoverable with just --list and can be added to bash/zsh/fish/etc autocomplete.

For example:

just build --profile release --os linux --arch amd64

I guess one concern with this is distinguishing what arguments/flags are for just and what arguments can be passed through to an underlying command

For instance:

just run --profile release --os linux --arch amd64 --foo --bar 42

Perhaps explicitly named arguments can be excluded from *ARGS (or maybe a new ...ARGS)

run --profile="release" --os="{{ os() }}" --arch="{{ arch() }}" ...ARGS:
  cargo build --profile {{ profile }} --target {{ os }}-{{ arch }}
  ./target/{{ profile }}/main {{ ARGS }}

Which executes:

cargo build --profile release --target macos-amd64
./target/release/main --foo --bar 42

[hisaac]

I guess one concern with this is distinguishing what arguments/flags are for just and what arguments can be passed through to an underlying command

One way I've seen that handled in some other tools is to use -- as a separator. Any args before that are for the tool, and any after get passed to the next program.

So for your example, it would look something like

just run --profile release --os linux --arch amd64 -- --foo --bar 42

Not sure how hard that would be to implement or if it would work here, just thought I'd mention it as some prior art.