serde_derive will be found within precompiled/bin when using git

[Astavie]

I'm unsure if this is intentional or not, but I'm currently unable to use serde as a dependency like this:

[dependencies]
serde = { git = "https://github.com/serde-rs/serde.git", features = ["derive"] }

When doing that, I get these errors:

error: proc-macro derive panicked
   --> discord/src/gateway.rs:131:10
    |
131 | #[derive(Deserialize)]
    |          ^^^^^^^^^^^
    |
    = help: message: failed to spawn process: Os { code: 2, kind: NotFound, message: "No such file or directory" }

This is because it tries to run serde_derive/serde_derive-x86_64-unknown-linux-gnu, a binary that is not included in the git repo and is not built automatically. It seems that it finds serde_derive within precompiled/bin/ before the it finds it in serde_derive/

This is does not happen when simply using the crates.io package, so this might seem inconsequential. However, this means it's harder to use serde forks as dependencies for testing purposes. I found this issue when trying to use my own fork:

[dependencies]
serde = { git = "https://github.com/Astavie/serde.git", branch = "integer-tags-for-enums", features = ["derive"] }

For now I have made another branch on my fork where I removed the precompiled folder, but it would be nice if this wasn't necessary.

[dtolnay]

Would you be willing to pursue any of the following fixes in Cargo?

1. Support an additional argument in serde_derive = { git = "https://github.com/serde-rs/serde", ... } that specifies the subdirectory within the repo where the requested crate is located, in this case subdirectory = "serde_derive"?

2. Something we can put into the manifest at precompiled/serde_derive/Cargo.toml to specify that it is not supposed to be selected when Cargo crawls the git repo looking for crates?

3. Increased precedence for top-level workspace members? The top-level Cargo.toml in the git repo is a virtual manifest that lists members = ["serde_derive", ...] but not "precompiled/serde_derive"; that is kept in a different workspace (in part because a workspace can only have one member per crate name).

4. Paying attention to path of git dependencies? When you have serde = { git = "https://github.com/serde-rs/serde" }, the serde crate manifest at serde/Cargo.toml specifies serde_derive = { ..., path = "../serde_derive" }, so it's pretty clear that that one is the right serde_derive to use in the build.

[Astavie]

Those could be viable solutions.

1. This is probably the simplest but then the library user is expected to know what the issue is. IMO using a git dependency should be as close to a drop in replacement as possible to using the crates.io version
2. This would solve this right now, yes, but would also prevent using the precompiled version if you actually intended to, no?
3. This also makes sense but would a breaking change. It also would only solve this specific issue, not the general issue where a git repo has multiple definitions for the same crate
4. This makes the most sense to me and I'm actually surprised it isn't already default behavior. I'll look into this some more later

[jayvdb]

This issue may no longer be relevant since https://github.com/serde-rs/serde/releases/tag/v1.0.184 removed the pre-compiled binaries.

[dtolnay]

Thanks @jayvdb. Closing, but I would still love to see any of #2526 (comment) implemented in Cargo.