I'll second Armin and Corey here; if lib A and B depend on different versions of lib C, you *must* still be able to easily build and link them together as deps of lib D. This is *critical* in large codebases where it's not feasible to go into A and B and update which version of C they depend on since A & B are possibly very big and have tons of other users who aren't as willing as you are to switch to a new version of C.
And now imagine a (frighteningly common) nightmare scenario, where the library version clash is not two steps away from you, but say 8 and 12. So you link something that depends on something that depends on something ... that 8 steps away depends on A (which depends on C v1), and a different chain of deps that 12 steps away depends on B (which depends on C v2). Good luck resolving that. Even more fun scenario: both A and B depend on C v1, but B wants to update to C v2 because of a new feature they need. And they can't, because it would break everyone upstream of them who depended on A. And no, you can't just go into A and update it to C v2 because maybe the API in C changed, maybe the same functions return slightly different results (a bug was fixed, but old code implicitly depends on the bug) and just maybe lib A is millions of lines of code and updating it would take weeks (or longer) for the team that maintains A in the first place, and God only knows how long it would take you. This is a huge problem in large C++ codebases. It is not fun. An example: every version of Xerces-C++ puts its code in a new C++ namespace<http://xerces.apache.org/xerces-c/program-others-3.html>, so code is in xerces_3_0, xerces_3_1, xerces_3_2 etc to prevent these kinds of issues. Not being able to link together different versions of a library together completely breaks encapsulation. Just don't go there. On Thu, Jan 30, 2014 at 4:27 PM, Armin Ronacher <[email protected] > wrote: > Hi, > > > On 30/01/2014 23:08, Tony Arcieri wrote: > >> What if the different versions of the library do incompatible things, >> like: >> >> - Talk incompatible versions of a network protocol >> - Serialize data differently >> - One contains important security fixes the other does not >> > They are different libraries. It's not an issue in practice because the > situation where this happens is if you have a library depending on another > library internally. > > Not having the option to run multiple versions of the same library in > parallel in different parts is a major problem and Python suffers > tremendously under this. > > > Regards, > Armin > > _______________________________________________ > Rust-dev mailing list > [email protected] > https://mail.mozilla.org/listinfo/rust-dev >
_______________________________________________ Rust-dev mailing list [email protected] https://mail.mozilla.org/listinfo/rust-dev
