Solver: try packages in global database first

[phadej]

See recursion-schemes/recursion-schemes#45

For some reason transformers-compat version is picked first. And as it can be satisfied solver doesn't backtrack to pick installed version of transformers but rather picks non-installed version of transformers.

Is there something I miss?

cc @grayjay

[kosmikus]

Well, it has to pick one of the two goals first. Goal order is generally determined by the solver in a heuristic way, such as "having few available choices" or "is known to lead to conflicts often". It's always possible to tweak the heuristics, but in most cases, changing them does not lead to clear benefits, but rather trades improvements for one package against regressions for others.

I'm not sure what the concrete suggestion here is. You want to solve for goals first where the package is contained in the global DB? If anything, I'd like to gradually move away from having what's currently installed influence the solver, so I'm not sure if I like a proposal that would move in the opposite direction. With new-build, there's basically hardly any reason anymore to take current installations into account for solving at all, except for packages which are truly locked of course.

[sebright]

This issue looks very similar to #2129. I would rather not restrict the goal order, because the solver already manipulates the goal order to try to find a solution faster, and that is more effective when it has more flexibility. I think @kosmikus's suggestion to compare multiple install plans in #2129 (feature request in #2860) would work well. Scoring install plans would mean that all package preferences could be given equal weight, independent of goal order. I can't think of a good short-term solution, though, besides adding "installed" constraints specific to the packages being built.

[sebright]

Combining install plan scoring with package upload timestamps (suggested in #2759 (comment)) would work well in this case, because the transformers-compat versions were released very close together.

[sebright]

Closing as a duplicate of #2129, because there is a discussion of an unnecessary upgrade of transformers and mtl in #2129 (comment).