Open dtolnay opened 2 years ago
As I have inspected, The latest version of serde_derive–which is 1.0.133–does not rely on serde_derive_internals. But serde_derive of version 1.0.0 relies on serde_derive_internals. (you can check it out here https://crates.io/crates/serde_derive/1.0.0/dependencies) As you can see, serde has ^1.0 spec. That means the API that I designed always sends a request for a base version (always put zeroes to spec before sending a request), which is 1.0.0. So that is why serde_derive_internals appeared on the dependency tree. If this diagnosis doesn't suit you, you could offer a solution. I don't really have an idea how to deal with this. 🤨
The fact remains that when someone builds this crate today, serde_derive_internals is not in their dependency graph. Cargo would pull in the newest serde_derive, which does not depend on it.
If this view is showing dependencies that the crate depended upon at some point but not anymore, I think that would make it pretty useless for most purposes.
the API that I designed always sends a request for a base version (always put zeroes to spec before sending a request), which is 1.0.0.
This seems like the issue. This is the opposite of what Cargo does, which is pull in the highest version compatible with the dependency spec.
Oh. I get your point. I will try to fix this by requesting the latest version, compatible with the spec. I might take time there. If the spec contains only two digits (major and minor), it will be hard and slow (due to multiple requests) to find the latest version. But, it will try. 😀
I noticed a crate called serde_derive_internals in the following dependency tree. From reading https://crates.io/crates/serde_derive_internals/reverse_dependencies, only a few crates depend directly on serde_derive_internals and I don't see any of them in that graph, so it's not clear where this transitive dependency is coming from.