4 ms·

No, this is not the silver bullet for solving dependency hell. Apart from the problem of maintaining all those older version code, the problem of creating diffe

No, this is not the silver bullet for solving dependency hell. Apart from the problem of maintaining all those older version code, the problem of creating different versions of the same function is already non-trivial. For imperative programming languages, you have preconditions on global states that depends on other functions to work correctly. Say, you have a certain access sequence for locks that has to be obeyed by all functions in this library. Suddenly in some version, you want to add another lock or expose some API that does things with finer granularity. Suddenly the precondition for older code breaks, so there is no guarantee that users can sometimes call the old version of the API and sometimes call a newer version of the API. I am not saying that the weird example I mentioned is a good way of programming, I just don't think that function versioning is the magic bullet to solving dependency hell. Intra-package dependency conflict is a difficult problem, neither the NixOS approach nor your approach can magically fix that.

0xbadcafebee 4y ago
Without a more detailed example I'm not sure how you mean (also I'm very tired) but it seems function versions would still solve that problem. A1 and B1 use library C1, and C1 has primitive locking. C2 is released with new locking. A2 is released which uses C2. B1 still runs against C1 still. If B1 tries to call A, it will call A1, both still use C1. If during development, A2 tries to call B, it will call B1, which, during the testing of A2, would fail (if B1 is incompatible with C2), so the developer of A2 would either have to implement a workaround, or upgrade to B2, and then A2 would be calling B2, which would work with C2. If A and B are developed independently, but some day somebody makes A and B try to talk together, and they were never tested together, they could either 1. make a best effort to try to work and then die, 2. compare mutual dependency trees and try to walk the trees to find versions of themselves (A and B) that work with the same version of a dependency (C), or 3. simply not run at all because they don't know what version of each other to use. In theory you could use CI/CD to build every version of every app against every version of every dep, store them all in a remote registry, so that whenever some weird combo of apps wanted to use something, they could look up a version of that app built against the right dep.
- pca006132 4y ago
  Yes, developers will need to implement workaround in the case when A1 and B1 cannot use the same version of C1. So how does the function versions approach solve the problem? For using CI/CD to build every version of every app against every version of every dependencies, even if we just ignore the problem of combinatorial explosion, some software may be abandonware and some may be entirely new. The set of versions of dependencies that work with them may not even overlap, so the 'correct' combination may not even exist. I think the function versioning approach is just a way to maintain backward compatibility, it is not required for backward compatibility, nor enough for backward compatibility.

0xbadcafebee 4y ago

Without a more detailed example I'm not sure how you mean (also I'm very tired) but it seems function versions would still solve that problem. A1 and B1 use library C1, and C1 has primitive locking. C2 is released with new locking. A2 is released which uses C2. B1 still runs against C1 still. If B1 tries to call A, it will call A1, both still use C1. If during development, A2 tries to call B, it will call B1, which, during the testing of A2, would fail (if B1 is incompatible with C2), so the developer of A2 would either have to implement a workaround, or upgrade to B2, and then A2 would be calling B2, which would work with C2. If A and B are developed independently, but some day somebody makes A and B try to talk together, and they were never tested together, they could either 1. make a best effort to try to work and then die, 2. compare mutual dependency trees and try to walk the trees to find versions of themselves (A and B) that work with the same version of a dependency (C), or 3. simply not run at all because they don't know what version of each other to use. In theory you could use CI/CD to build every version of every app against every version of every dep, store them all in a remote registry, so that whenever some weird combo of apps wanted to use something, they could look up a version of that app built against the right dep.

pca006132 4y ago
Yes, developers will need to implement workaround in the case when A1 and B1 cannot use the same version of C1. So how does the function versions approach solve the problem? For using CI/CD to build every version of every app against every version of every dependencies, even if we just ignore the problem of combinatorial explosion, some software may be abandonware and some may be entirely new. The set of versions of dependencies that work with them may not even overlap, so the 'correct' combination may not even exist. I think the function versioning approach is just a way to maintain backward compatibility, it is not required for backward compatibility, nor enough for backward compatibility.