3 ms·

> Let's look at Python for example. If you want to install a package, it goes into /usr/lib/python3.11/site-packages/$PACKAGE. Do you want two version of it? Th

by rlpb 3y ago

> Let's look at Python for example. If you want to install a package, it goes into /usr/lib/python3.11/site-packages/$PACKAGE. Do you want two version of it? That's not possible. This is ultimately a language design issue. Python virtualenvs make this possible, and are accommodated for in Python's design decisions. I therefore don't think it's fair to say "that's not possible". You do need entirely distinct stacks, but that's necessary by definition. You can't have package A depend on packages B and C each of which depend on a different version of package D but expect to share API objects from D back through to A and therefore with each other. This would require some level of compatibility between versions of D, and there can be no guarantee of that.

eqvinox 3y ago
> You do need entirely distinct stacks, but that's necessary by definition. You can't have package A depend on packages B and C each of which depend on a different version of package D but expect to share API objects from D back through to A and therefore with each other. Shared objects do in fact allow doing the safe subset of this, which is to load 2 versions of D that are used by packages B and C without exchanging API objects. The C language has no good mechanism for enforcing this separation, as only one version of D's headers will be in use when compiling A, B and C. That said, there is a non-negligible number of situations (especially with libssl) where this is irrelevant because D is internal to one or both of B and C.
- rlpb 3y ago
  > Shared objects do in fact allow doing the safe subset of this, which is to load 2 versions of D that are used by packages B and C without exchanging API objects. It's a fair point. But in practice this can only be done when the versions of D have different sonames - at least with the usual filesystem layout we use for dynamic linking. In that respect, Python can do it too - we just don't typically embed the major version into our Python module names, as is typical with sonames.

by rlpb 3y ago

eqvinox 3y ago

> You do need entirely distinct stacks, but that's necessary by definition. You can't have package A depend on packages B and C each of which depend on a different version of package D but expect to share API objects from D back through to A and therefore with each other. Shared objects do in fact allow doing the safe subset of this, which is to load 2 versions of D that are used by packages B and C without exchanging API objects. The C language has no good mechanism for enforcing this separation, as only one version of D's headers will be in use when compiling A, B and C. That said, there is a non-negligible number of situations (especially with libssl) where this is irrelevant because D is internal to one or both of B and C.

rlpb 3y ago
> Shared objects do in fact allow doing the safe subset of this, which is to load 2 versions of D that are used by packages B and C without exchanging API objects. It's a fair point. But in practice this can only be done when the versions of D have different sonames - at least with the usual filesystem layout we use for dynamic linking. In that respect, Python can do it too - we just don't typically embed the major version into our Python module names, as is typical with sonames.