Barry Warsaw writes:
> Where things get tricky is if you have multiple applications that need
> different versions of its dependencies. Say Debian has python-foo 1.2
> which application Bar needs, but application Baz needs python-foo 2.0.
> Despite years of discussion, in Debian, Ubuntu, and upstream, we really
> don't have a good multi-version story. I think that's forgivable though
> because it's a Really Hard Problem and nobody's stepped up to pay a team
> of 5 gurus for the 25 man years of non-stop work it would probably take
> to solve (both technically and socially ;). This problem isn't
> particularly limited to Python.
I keep being tempted to go off on a rant about how we have all of these
modern, sophisticated, much more expressive programming languages, and yet
still none of them handle ABI versioning as well as C does. Normal
versioning problems that we just take for granted in C, such as allowing
the coexistence of two versions of the same library with different ABIs on
the system at the same time without doing the equivalent of static
linking, vary between ridiculously difficult and completely impossible in
every other programming language that I'm aware of (with the partial
exception of C++ where it is possible to use the same facilities as C,
just considerably more difficult).
In fact, most new languages seem to be *regressing* here. Both Perl and
Python were already fairly bad at this, Java bailed on the problem and
shoved it under the carpet of a version of static linking, and now Go is
even worse than they are and is explicitly embracing static linking.
It's immensely frustrating that this doesn't appear to be an interesting
problem to language designers, and even brand-new, sophisticated languages
that are trying to be at the cutting edge of language design do not make
any serious attempt at solving the ABI versioning problem.
Everyone could stand to learn something from the REST and web services
community, where ABI versioning is a well-known and widely accepted
problem that regularly prompts considerable discussion and careful thought
and a variety of useful proposals for addressing it with different
tradeoffs. It's kind of sad when one's brand-new, cutting-edge
programming language does a worse job at a foundational requirement of
language ecosystems than the Facebook API.
Russ Allbery ([email protected]) <http://www.eyrie.org/~eagle/>