Ivan Petkov

I didn't see anything glaringly wrong in your configuration, but at the same time I couldn't spot anything in our own sources (generally things just pass down the original source...

Hi @OliverNChalk thanks for the report! This looks like a gap in our implementation: tests (and examples and benches) are [detected if they are declared in `Cargo.toml`](https://github.com/ipetkov/crane/blob/e316f19ee058e6db50075115783be57ac549c389/lib/mkDummySrc.nix#L309-L311) but we're missing...

Hi @hustlerone thanks for the report! Do you have a reproduction flake I can take a closer look at?

Thanks I was able to spot the issue: cargo is unhappy if any concrete `workspace.member` paths are missing from the sources. The trick is to use a wildcard so that...

This would unfortunately require a breaking change, with the alternative being to introduce a new method to return the signal itself. ~~Though FWIW a signal handler will always fire on...

Is the application code in question registering interest in any OS signals? Whenever *any* signal is registered for the first time, tokio will register an OS signal handler and then...

Hi @simonzkl thanks for the report! Even if `nixpkgs`'s `fetchCargoVendor` does end up supporting custom registries, it would still be useful to have our own equivalent, namely that can reuse...

I second everything that has been said earlier. There's nothing `crane` specific about using overlays, any _general_ documentation around them (and any advice when to use `final` vs `prev`) would...

> your stance is also that it's not 100% clear which to use between `final` and `prev`? No. My stance is that is _is_ clear which one to use, but...

Hi @P-E-Meunier thanks for the PR! > Unfortunately, Crane needs special handling of this case since the Cargo.lock resulting from such workspaces has no registry source nor hash for the...