Rain

Thanks for the report. This most likely occurs due to nextest needing to fetch `cargo metadata`, which doesn't have a way to exclude packages from consideration. I don't think nextest...

cargo-hakari maintainer here. I absolutely support this work in general -- hakari was always meant to be a stop-gap solution. Going down the list of hakari's [config options](https://docs.rs/cargo-hakari/latest/cargo_hakari/config/index.html): Most of...

@kornelski per-feature caching is already the case. I don't consider its performance characteristics acceptable in large projects personally, which is why I maintain hakari.

@weiznich I'm deeply sympathetic to your concern. At the same time, I believe the current state of feature unification in Cargo is truly and utterly unacceptable for larger projects. I've...

Really appreciate your perspective @weiznich. > While I totally can understand that conclusion I just want to clarify here again: You basically say, we need this for omicron/ a similar...

> If that's so widespread it shouldn't be too hard to provide some exact numbers that say: "We measure a speedup of x in this cases. You can reproduce this...

Thanks. This would definitely be very useful, but camino mirrors Path's stable API so I'm inclined to not add this feature for now. What do you think of copying that...

Thanks. I think this should not live in Camino itself — and it's quite straightforward (most of the complexity is in shell quoting which is delegated) so maybe just have...

Though maybe this can be an optional displayer enabled by a feature on camino, hmm.

> Do you mean the {:#} alternate for Display? A goal here for this is to work with Path too...I may actually try to rework this to be an extension...