Allowing customization of cargo nextest command

[bluesheeptoken]

First of all, thanks for maintaining the project, I appreciate !

In our CI, we are using Nix for reproducible environment. And in this context when issuing a cargo-insta, it points to /nix/store/[hash]-cargo-insta/bin.

And when using nextest as the runner, cargo-insta expends the command to cargo nextest run with nextest not in our ~/.cargo/bin.

I think it makes complete sense to use the same cargo that started the cargo insta command. But in our case, we would like cargo-nextest to be invoked instead of cargo nextest.

Would it make sense to be able to replace it? Or is it too niche?
Or is there any other solutions I am not seeing with rust to make cargo nextest points to cargo-nextest?

I'm a bit of a newbie to Rust and rust toolchain, so my assumptions might be wrong, don't hesitate to double check them :)

Edit: Obviously, if this is doable and makes sense to integrate here. I will implement the feature !

[max-sixty]

I'm open to it; I also don't know enough about how cargo & paths work to be able to assess whether it's always OK to defer to cargo-nextest. Is it right to think that it could be different from cargo nextest when:

• there's a cargo-nextest in the system path before cargo
• it points to something different to the cargo-nextest in the default ~/.cargo/bin
  ?

A couple options:

• We could add a "test runner path" config
• Or possibly attempt to identify when a path is passed to --test-runner and use that. The latter would require you to pass a path rather than just cargo-nextest, and we'd need to consider how to handle not knowing whether nextest is being called (we currently do a couple of things slightly differently)
• I tried to see whether there was an env var you could pass to get cargo test to invoke a different binary, but couldn't find one

[bluesheeptoken]

there's a cargo-nextest in the system path before cargo
From what I've read in cargo so far, even if cargo-next is in the path before cargo, the cargo-nextest called is the one cargo decides (usually ~/.cargo/cargo-nextest.
it points to something different to the cargo-nextest in the default ~/.cargo/bin
Completely true 👍

I kinda like the first option, (I didn't know there could be a config, I was thinking about an env var at first). This would avoid adding a confusing command line that 99% of the callers won't care about.

For the second option, I am afraid end-user will get confused wether to use a path or an enum for the same argument.

So I would go for the first option. WDYT?

[max-sixty]

OK great!

Assuming it's consistent with the existing configs + we add a bullet to the docs, I'm good to merge an env var...

[bluesheeptoken]

Awesome ! I'll give it a try using a config first. Seems cleaner and I don't think there are other features using env Var. I'll ping you once I have something I am happy with. Thanks for your time :) Le ven. 7 févr. 2025, 23:18, Maximilian Roos ***@***.***> a écrit :

…

OK great! Assuming it's consistent with the existing configs + we add a bullet to the docs, I'm good to merge an env var... — Reply to this email directly, view it on GitHub <#718 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AEHWBOLNO5UBHS7VD2BIX6D2OUWMBAVCNFSM6AAAAABWTSKBNCVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDMNBUGIZTAOBQGM> . You are receiving this because you authored the thread.Message ID: ***@***.***>

[max-sixty]

(FYI there are lots of features using an env var! Search for INSTA_, lmk if you need more info)