amos

> So two dependency graphs that are logically equivalent but list deps in a different order could theoretically get different resolution

What. What!

Mar 10 at 11:55pmWeb
Show threadOwen NelsonMar 10
@fasterthanlime I hate this
Show threadRiley Labrecque🎏Mar 11
@fasterthanlime Could we just not tho?
Show threadamosMar 11
@rlabrecque Things are hard! What’s a better solve:
foo@1 + bar@4, or
foo@2 + bar@3?
Show threadRiley Labrecque🎏Mar 11
@fasterthanlime what if we just vendor everything and only have 1 version 🙃
Show threadldvsoftMar 11
@fasterthanlime sounds like Maven
Show threadBen ZaninMar 11

@fasterthanlime oh no

This sounds like what @juliank has been wrestling with lately

Show threadJulian Andres Klode 🏳️‍🌈Mar 11

@gnomon @fasterthanlime this probably happens in most solvers because we all build them around SAT solvers and tweak their variable selection.

If you construct them around a global optimization function instead like in pseudo boolean optimization you can likely avoid this (not that I have a proof for it).

For distro package management that's an unsolved problem because if you say "minimize installs" it would pick backend-sqlite over a preferred backend-mysql; but language pms may be fine?

Show threadJulian Andres Klode 🏳️‍🌈Mar 11

@gnomon @fasterthanlime So a language package manager that allows concurrent versions should get the right result if it can optimize over a global function

maximize(highest version) than minimize(installed)

Whereas for example APT could have a tie still between two identical packages A and B and would need another criterion to say minimize(alphabetic)

Show threadamosMar 11
@juliank @gnomon that matches my understanding, yeah. there's no "mutiple packages provide this" in Cargo, or "this package excludes that other packages", there's "only" version ranges
Show threadRob MayoffMar 13
@fasterthanlime oh, you wanted your graph rewrite rules to be *confluent*? I thought you said *effluent*