Confusion behavior when running multiple recipes on line and the first of them has variable parameters (or optional one)

[jancespivo]

With justfile:

foo text='FOO':
   echo {{ text }}

bar:
   echo "BAR"

just foo bar executes only foo recipe with parameter bar

The even more confusion we experienced was when the first recipe lost its parameters:
Now just foo bar executes both recipes.

This can be super harmful mainly in CI, when it accidentally runs two recipes instead of one or vice versa. It is hard to notice it has different behavior than it had before.

I understand the main selling point is deduplication of shared dependencies and I don't have the "right" proposal how to have safe behavior and dedup together in all cases.

However for our use case there could be a new settings that will disable the possibility to run multiple recipes on one line.

[runeimp]

Ah, good idea! I was going to point out this is just an issue with the command line in general but that is a good fix!

[casey]

Although I've never personally run into this, it has come up a few times. One idea would be to add an optional explicit grouping operator, probably […], since those aren't shell special characters. So if you wanted to call foo and bar, and make sure that bar isn't used as an argument for foo, you would write:

just [ foo ] [ bar ]

This is kind of verbose and annoying though. I don't think I would want to add a setting in the justfile itself, because something that controls how the command line is parsed doesn't feel like it belongs in a setting.

Another option is to add a flag, like -1, --one, or --only, which would restrict an invocation to a single recipe, and throw an error if the command line was parsed into multiple invocations. This would require you to call just multiple times:

just --only foo
just --only bar

Overall none of these options feel great.

[runeimp]

I like the --only option for specifying that only the following argument is a recipe name. And something like ‑‑multiple, ‑‑multi or ‑‑only-recipes-left-alive could specifically signal that anything that looks like it has multiple recipes is intentional. Having neither in an ambiguous situation would trigger an error. Forcing the user to specify one or the other to alleviate the ambiguity.

The only issue I see with that is it could be a breaking change for many projects. Maybe hide the feature behind an edition?

Hmm, the grouping thing is probably a better solution though. Is the following what you were suggesting @casey?

just [foo arg1a arg2a] [bar arg1b arg2b]

With maybe a shorthand not requiring the grouping symbols for the last group?

just [foo arg1a arg2a] bar arg1b arg2b

[laniakea64]

Related to #1556

For the grouping operator idea, to keep possible to pass all values as parameters, what about borrowing an idea from Rust's raw strings syntax: The opening delimiter can be any number of [, but the closing delimiter has to be the exact same number of ] as in the opening delimiter.

To run recipe foo followed by recipe bar, with all default values for foo's parameters

just [ foo ] bar

To run recipe foo with "]" as its first parameter and its other parameters at default values, followed by running recipe bar

just [[ foo ] ]] bar

There is still the caveat that the opening [s need to be in a position where they cannot be considered a parameter.

Another possibility could be a command-line option which, if set, enables using opening and closing delimiters and defines what they are:

just --recipe-delimiter '[[' ']]' -f justfile [[ foo ]] bar

The -1, --only flag seems like a more straightforward solution than any grouping operator.

[jancespivo]

I like --only flag. It would be great to possible to set it as environment variable as well, so we can set it in CI globally and don't mind that ;)

[casey]

Draft PR here which adds a --one/-1 flag, which can also be set with the environment variable JUST_ONE, to only allow one recipe to be invoked per command line.

[casey]

Added the --one flag in #2374. I decided to remove the short, -1 version, since this will probably not be an extremely frequently used feature, and there might be some other fun use for integer flags.