So, what exactly does --preference DO?

[ezyang]

I've been beavering away on the Nix-local build documentation, and I discovered that --preference is not documented. I tried to add docs for it... but I have no idea what this option actually does. Like, I have an informal idea, but is there any solid semantics we can give for it?

CC @dcoutts @kosmikus

[ezyang]

Also CC @grayjay

[phadej]

To my understanding, it alters a "which version is better" heuristics, similarly as deprecation on Hackage. I hope that the effect is the same in semantics, but opposite.

[ezyang]

If there exists a valid install plan which satisfies all the preferences, am I guaranteed to get it? If the preference set is unsatisfiable, do I get a solution which minimizes the number of unsatisfied preferences?

[phadej]

"minimizes" is a strong word. The heuristics are cost (or actually penalty) based, so yes you should get a solution with minimal penalty, but what's relative penalties of non-preferred package and deprecated one (i.e. what's better, one deprecated or two non-preferred) are something hard-coded which "no one knows". But if there're two preferences, and cabal have to break either one: I guess the choice is practically non-deterministic.

Correct me if I'm wrong, but I guess preferences work with costs too (i.e. adds penalty to not-preferred versions)?

[grayjay]

We can't make many guarantees with the current implementation. The solver applies different types of preferences by sorting the choices for each package in the search tree, so that it tries versions in order from most to least preferred. Then it returns the first solution. Preferences never cause the solver to backtrack.

The preferences used by the solver are, from strongest to weakest: preference for linked packages, preferences from Hackage and --preference, and preference for newer or installed packages. Preferences from Hackage and --preference are combined by counting the number of preferred version ranges that a version satisfies, i.e., the two types have equal weight. So I think that the only guarantee is that when the solver finds an install plan, no single package could be replaced with a more preferred version and still satisfy the hard constraints (if "preferred" includes all types of preferences).

#2860/#2917 would add scoring and could be used to minimize the number on non-preferred packages.

[ezyang]

OK, thanks. I'll work the results of this discussion into the documentation I'm writing.