Szorc: Mercurial's Journey to and Reflections on Python 3

Posted Jan 15, 2020 9:10 UTC (Wed) by roc (subscriber, #30627)
In reply to: Szorc: Mercurial's Journey to and Reflections on Python 3 by NYKevin
Parent article: Szorc: Mercurial's Journey to and Reflections on Python 3

Are such environmental collisions any more of a problem in practice for multiple versions of the same library coexisting than for different libraries coexisting?

I'm familiar with libraries stomping on each other at run-time, e.g. with races around fork(). I'm familiar with C libraries stomping on each other with symbol collisions during linking. I've even had listening port collisions with two components in the same container. But my Rust project links multiple versions of some libraries (which libraries, and which versions changes over time), and I haven't had any problems with that so far in practice.

Szorc: Mercurial's Journey to and Reflections on Python 3

Posted Jan 15, 2020 21:23 UTC (Wed) by mathstuf (subscriber, #69389) [Link] (1 responses)

It is much more likely that two versions of the same library will share symbols than different libraries. The latter can probably be avoided by not exporting all symbols by default or adding a few strategic `static` keywords. The former…well, Python2 and Python3 can't be mixed in the same process because they share symbol names. Same with glib and other projects that tend to be "good citizens" with their ABI management.

Rust avoids the symbol problems, but still has woes with libraries trying to control any global resource (signal handlers, environment variables, etc.).

Szorc: Mercurial's Journey to and Reflections on Python 3

Posted Jan 15, 2020 21:38 UTC (Wed) by roc (subscriber, #30627) [Link]

Yes I understand that for C-like linkage multiple versions of the same library are a disaster.

Signal handlers are just a massive problem in general --- for different libraries as well as for two versions of the same library. For that and other reasons I have not encountered any Rust crates (other than tokio-signal) that set signal handlers. Likewise setting environment variables is a minefield libraries should avoid under any circumstances.

So I agree that two versions of the same library are more likely to hit these issues than two different libraries, but I'm not convinced that *in practice* it's really worse, for Rust.