How to run an arbitrary command with ./target from crane derivation?

[dpc]

I have a set of tests (already written) that are basically:

cargo build --release
# run bunch of stuff using the binaries in `./target/release/...`

I'd like them to be able to reuse the binaries from the existing crane step that I have (making cargo build --release a no-op, as everything is already compiled).

I guess maybe I can go with cargoBuild and override cargoBuildCommand to run my custom script, but ideally a separate command would be neat.

[ipetkov]

Yep, the idea is you can either override cargoBuild or go straight to mkCargoDerivation to add whatever custom behavior you'd like!

The only (real) difference between the two is that cargoBuild will automatically call vendorCargoDeps and buildDepsOnly for you. All the other existing cargoWhatever commands are basically small tweaks on top of cargoBuild so you should be able to adopt the approach for any custom workflow you need!

This is if you actually need to invoke cargo itself. If you just care about the binaries you can always "install" them as a derivation's output and then write another derivation that tests them further, but that's up to you!

[dpc]

If you just care about the binaries you can always "install" them as a derivation's output and then write another derivation that tests them further, but that's up to you!

The problem with that is if you want to write some more complex e2e/integration tests, you want them to work for developers locally, and usually developers will expect to test stuff straight from their ./target/release and not from binaries compiled and available in the $PATH.

I'm trying cargoBuild with overriden cargoBuildCommand. I think it will work, but would be easier for people less familiar with crane to read and understand if it was named cargoRunArbitary or something like that. Also it could disable any extra stuff.

[ipetkov]

I'm trying cargoBuild with overriden cargoBuildCommand. I think it will work, but would be easier for people less familiar with crane to read and understand if it was named cargoRunArbitary or something like that. Also it could disable any extra stuff.

Figuring out what is "extra stuff" depends on the person using it ;)
I don't see a ton of value adding an entire API for cargoRunArbitrary as a thin wrapper on cargoBuild as cargoBuild is already meant to be easily overridable by consumers.

Unless cargoRunArbitrary would be able to do something which is impossible via cargoBuild alone, then I'd be curious to hear more about the use case

[dpc]

Fair enough. Using cargoBuild works fine with me. I kind of assumed that such a wrapper would be very "lightweight" (in terms of complexity, documentation and such). It's really not a big improvement or a must-have by any means indeed.

[ipetkov]

I'm definitely open to considering adding convenience wrappers which orchestrate complicated set ups so if you find something super useful feel free to post about it and we can take a look at it case-by-case 😄