Does not correctly handle cross-workspace dependencies.

[dpc]

I know, I have a most complicated build that ever existed... :D

For complicated reasons, that I can't get into RN my project structure is more or less:

root
  client
  client-lib-x
  api
  server

The client and server are a different workspace. But they both include the api as path = "../api".

So I'm running cargo-chef inside both server and client, but then cargo chef cook gets totally confused, and says:

Caused by:
  Unable to update /app/app/api 
                                                                                                                     
Caused by:                                                                                                           
  failed to read `/app/app/api/Cargo.toml`  

Even though path ... should be ... Hmmm... /app/api/Cargo.toml . Seems like some path concatenation somewhere where wrong WRT ...

[LukeMathWalker]

This is a bit of a tricky one (and a limitation I was aware of unfortunately) - how should it handle out-of-root path dependencies?
How would the stuff we do for in-root path dependencies (creation of dummy lib.rs/main.rs, clean-up of library compilation artifacts) work for those?

[dpc]

That's exactly what I've been doing before cargo-chef. I copied all toml and lock files, added stub main.rs/lib.rs in each project and it worked just fine. All the dependencies got built.

Part of the reason I'm interested in converting to cargo-chef because it was quite a lot of steps in the Dockerfile and rather confusing for anyone who was not experienced Rustacean.

[LukeMathWalker]

To make it possible with cargo-chef we need to remove the assumption that the command is being run from the root of a cargo project/workspace.
It's certainly possible, I just need to work our the ergonomics of it. Can you put up a minimum repo with dummy files that mirrors the structure of what you are working on? It'll make it easier for me to test.

[dpc]

I'm running these commands from the root the workspace. The external dependencies are not part of the workspace and are side by side with it. I'll try to minimize my setup and sent something along your way.

[oeed]

Following my similar issue #51, I (probably naively) suspect that recursively collecting all dependencies from path dependencies, but omitting the path dependencies themselves, might solve this?

Is the issue of being run from the root one of where to find/copy the files once in Docker?

[LukeMathWalker]

@oeed - I haven't had time to work on this, but I am convinced it's definitely possible to support it.
This issue just needs a dedicated developer willing to open a PR for it.

[markdingram]

I started the ball rolling in #169 - it is working against a simple local test - if it looks promising to eventual merge I'll add an integration test next.

In the meantime I'll kick the tyres on this in CI to see if it holds up against a more realistic setup.

[markdingram]

Wrote up a workaround to this issue in https://github.com/markdingram/cargo-chef-multi-workspace