-
Notifications
You must be signed in to change notification settings - Fork 113
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Does not correctly handle cross-workspace dependencies. #4
Comments
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? |
That's exactly what I've been doing before Part of the reason I'm interested in converting to |
To make it possible with |
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. |
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? |
@oeed - I haven't had time to work on this, but I am convinced it's definitely possible to support it. |
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. |
…rent Workspace) Restrictions: - if external Packages are part of a separate Cargo Workspace then at least one must link to that Workspace via the Cargo 'package.workspace' key - external Workspaces are recommended to use wildcard globs for members, to avoid errors when not all children are included by cargo-chef Fixes LukeMathWalker#4
…rent Workspace) Restrictions: - if external Packages are part of a separate Cargo Workspace then at least one must link to that Workspace via the Cargo 'package.workspace' key - external Workspaces are recommended to use wildcard globs for members, to avoid errors when not all children are included by cargo-chef Fixes LukeMathWalker#4
…rent Workspace) Restrictions: - if external Packages are part of a separate Cargo Workspace then at least one must link to that Workspace via the Cargo 'package.workspace' key - external Workspaces are recommended to use wildcard globs for members, to avoid errors when not all children are included by cargo-chef Fixes LukeMathWalker#4
Wrote up a workaround to this issue in https://github.com/markdingram/cargo-chef-multi-workspace |
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:
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 thencargo chef cook
gets totally confused, and says:Even though path ... should be ... Hmmm...
/app/api/Cargo.toml
. Seems like some path concatenation somewhere where wrong WRT..
.The text was updated successfully, but these errors were encountered: