Project has two dependencies, each having extra dependencies, nothing unusual here.
Dependency A depends on serde_json = "=1.0.85".
Dependency B depends on serde_json = "1.0.90".
This creates a conflict, since A wants specifically 1.0.85 while B wants at least 1.0.90.
Currently I am solving this conflict by pulling dependency A source into my source tree, apply a patch changing it into serde_json = "1.0.85" and referring to my local copy.
I don't really love this solution, as it could cause issues, but I haven't been able to come up with another one other than trying to get maintainer of dependency A bump their version and/or get rid of this strict version dependency, but that might or might not happen.
Are there any other "better" ways to solve this?
As far as I know you can use multiple versions of the same dependency, just giving it different names, but that doesn't really work as in this case it isn't a direct dependency that is causing the problem.
This is the real problem. If a library in my dependency tree did this anywhere, my next step would be to file an issue against that dependency about it. If they resist changing it and there is no extremely compelling reason to keep the = constraint (I personally cannot even think of such a reason), then my next step would be to figure out how to remove that dependency from my tree. If I depend directly on it, then it's easy: I can either re-roll the functionality or I need, or in the simplest case, fork the dependency and re-publish it without the = constraint.
= constraints are, I guess, "anti-social" for exactly the reason you came here: they result in unresolveable dependency conflicts. You really only have two choices. Convince the maintainer to drop it or drop the dependency.
Version constraints like <X and =X in libraries that are intended for others to use are really bad ideas. A <X or =Xmight be a reasonable thing to do very briefly to work-around some more disastrous situation, but it would be an exceptional case. As I said above, it's hard to even imagine such a case.
If the maintainer insists on keeping that = constraint there, absent some kind of exceptional circumstance, I'd probably also be looking to remove any other crate in my tree that is maintained by the same person/organization. Yes, it's that bad, and IMO shows extremely poor judgment to the point of damaging trust.