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

<ADDITIONAL_JOB_ARGS> are passed to cargo check when switch from run to check task #122

Closed
d4h0 opened this issue Mar 19, 2023 · 5 comments

Comments

@d4h0
Copy link

d4h0 commented Mar 19, 2023

Hi,

If I execute bacon run -- foo, and then press Ctrl+d to switch to the default task (i.e., run), I get the following error:

error: unexpected argument 'foo' found

Usage: cargo check [OPTIONS]

For more information, try '--help'.

Basically, cargo check doesn't allow additional arguments.

This could also be true for other tasks (e.g., test), but I'm not sure.

@Canop
Copy link
Owner

Canop commented Mar 19, 2023

Do you suggest the arguments after the double-slash (["foo"] in your example) should be given only to the initial job ?

And what if somebody wanted to have them given to all jobs ?

Opinions welcome

@d4h0
Copy link
Author

d4h0 commented Mar 19, 2023

The thing is that cargo run -- foo is valid, and cargo check -- foo is not valid. cargo check rejects additional arguments, because that doesn't make sense (the application isn't run, so command line arguments are not used).

So I believe the correct thing to do, would be to just not pass additional arguments to tasks that don't support them. build probably doesn't support additional arguments, as well (because the app isn't run, so command line arguments are not used).

If the user switches back to a task that supports additional arguments (e.g. run), then the additional arguments would be used again.

Do you suggest the arguments after the double-slash (["foo"] in your example) should be given only to the initial job ?

Ideally, additional command line arguments would be given to all tasks that accept them, but not others.

And what if somebody wanted to have them given to all jobs ?

This wouldn't work, because check for example just returns an error if someone passes in additional command line arguments for the application.

@Canop
Copy link
Owner

Canop commented Mar 19, 2023

cargo check does accept additional arguments.

You can do this today :

bacon check -- --all-targets --features "myfeature"

So bacon would have to know whether the arguments are used by the job executable in a direct manner or not ?

@d4h0
Copy link
Author

d4h0 commented Mar 19, 2023

Ah, I see. I thought the -- of bacon is like the -- of cargo.

However, that doesn't change much. In this case, the issue is with bacon run -- $ADDITIONAL_TASK_ARGS -- $ADDITIONAL_PROGRAM_ARGS (e.g. bacon run -- -- foo).

-- $ADDITIONAL_PROGRAM_ARGS should not be passed to tasks that don't allow additional command line arguments.

So bacon would have to know whether the arguments are used by the job executable in a direct manner or not ?

Cargo allows additional command line arguments (without the --) as long as they don't conflict with Cargos command line options. So in theory Bacon would need to figure out what arguments are intended for Cargo and which are intended for the application.

But I think, it would be reasonable for Bacon to require -- -- for passing additional arguments to the application.

SuperTux88 added a commit to SuperTux88/adventofcode-rs that referenced this issue Dec 20, 2023
This is a wrapper script for bacon calling cargo commands. This allows
to select only one day with "bacon -- --day 1", but fixes the problem,
that different cargo commands need this information in a different
format (run/test/bench) or some cargo commands don't take parameters
like this at all (check/clippy). So it calls all the cargo commands with
parameters which work for them.

See: Canop/bacon#122
@Canop
Copy link
Owner

Canop commented Oct 13, 2024

I think the extraneous_args = false may solve the problem.

@Canop Canop closed this as completed Oct 13, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants