Luca Palmieri
Luca Palmieri
I have seen the PR but I haven't had time to review it yet @prestontw - I'll provide feedback here when I do :)
The first row is not an option I am afraid - I want to maintain a minimal CLI interface for `cargo-chef` and I don't think this usecase is big enough...
Now I got it 😁 The second option you put forward seems to be the most appropriate. I still don't fully understand the con you mentioned though: > Forces users...
> Then when we skelefy `codegen`'s `lib.rs`, we obliterate this `switch` declaration: I think this is the part that confuses me - why is `codegen` in your local filesystem if...
Or are we working under the assumption that the patched version of `Pear/lib` brings the whole workspace/large parts of it due to path dependencies?
Sounds good to me! I wonder if you can determine the local path dependencies using `Cargo.lock`, therefore fixing the issue of transitive "patched" dependencies in one go.
You are right unfortunately - the lockfile is not very helpful in this case. Traversing the manifests seems a good alternative option.
> > Traversing the manifests seems a good alternative option. > > Do you think that the complexity of traversing manifests is worth it? The alternative is adding more directories...
The release profile is an orthogonal concept to development dependencies - e.g. you can build your test using the `--release` flag. We could enhance `cargo-chef` to determine if tests are...
Hey! Can you provide a small project where I can reproduce the issue?