Fix resolvo treating options as var requirements

[jrray]

This test is a minimal reproduction of a problem we found when using the resolvo solver. Please read the test code first to understand the package relationships involved. The step solver passes the test because it solves successfully; the resolvo solver fails to solve with the following error:

The following packages are incompatible
└─ my-app:run my-app:run cannot be installed because there are no viable options:
   └─ my-app:run mem-01k4x9e8jtsez9ebc3qs1qtcg4/my-app/4.5.6/TSZZLWXD:run would require
      └─ openimageio:run openimageio:run/Binary:1.2.3, which cannot be
  installed because there are no viable options:
         └─ openimageio:run mem-01k4x9e8jtsez9ebc3qs1qtcg4/openimageio/1.2.3/XFWQWLQ2:run is
            excluded because build option spi-platform does not satisfy global var request:
            ~2025.1.1.1 does not intersect with ~2024.1.1.1

In the test the solver is invoked in a way to mimic solving for a build environment (it is in an spk build where we have the problem in the real world), or similar to spk env -o spi-platform=~2025.1.1.1 my-app.

The step solver doesn't think this is a problem but I'm struggling to understand why. If I say -o distro=rocky then I definitely expect that the solver won't pick any builds that have - var distro/centos, so what is different about the spi-platform var here? Why is the step solver willing to pick a build that has a different major version?

I'm not convinced the step solver is right here, but assuming it is, I need to understand what is wrong about how resolvo is operating. For example, if I comment out the part of the resolvo code that causes it to exclude the mismatched option, then 10 of the preexisting solver tests start to fail. If it is supposed to ignore mismatched options under a specific set of circumstances, what are those?

Edit: the mystery around host options being enforced was answered (see comments) and the step solver is working as intended (modulo options not really doing anything) so this PR changes resolvo to match the behavior of the step solver to the extent of our test coverage.

[jrray]

@rydrman I would appreciate your input here.

[rydrman]

IIRC this is not the same as adding actual Var requests to the solver - the options only guide things but are not requirements to be satisfied

[rydrman]

https://github.com/spkenv/spk/blob/main/crates/spk-cli/common/src/flags.rs#L299

[jrray]

Host options get lumped in with the other options but they are hard requirements. 🤔

[jrray]

But it is true that if I add an actual var request then both solvers fail as unsolvable.

[rydrman]

The step solver once used the current set of options as hard requirements, but it hasn't been that way for a long time. So I think resolvo should to the same - it can guide with these if needed but shouldn't consider them constraints - only actual requests.

I can only assume that the host options are also getting injected as requests through either the above or some other code path...

[jrray]

On a lark I tried changing the resolvo code to completely ignore options and all the tests now pass. I think this says more about the test coverage than it does about resolvo.

[jrray]

This is the one test that calls solver.update_options with a non-empty OptionMap:

spk/crates/spk-solve/src/solvers/solver_test.rs

Line 1117 in 16abbd4

solver.update_options(option_map! {"debug" => "on"});

When I comment out that line the test still passes.

[jrray]

@dcookspi pointed out that outside of the solver we are turning options into var requests, including host options so I think that explains how host options become hard requirements.

spk/crates/spk-cli/common/src/flags.rs

Lines 299 to 300 in 16abbd4

	for r in options.get_var_requests()? {
	solver.add_request(r.into());

It also suggests that it would be a proper change to make the resolvo internals stop turning options into var requests itself. That does make the new test pass. But we need more tests to show what the expected behavior is in the presence of options. Up to now resolvo has been treating all options as hard var requirements and it has taken a decent amount of time for that to show up as a problem in practice. After the change to not turn options into var requests is in place, resolvo won't be using options for anything.

I'm imagining a test where the repo has many variants of the same package with a color var set to red, blue, etc. Then if there is an option color=red set it should "prefer" to pick the red build, but that is not strictly mandatory for correct behavior if I'm understanding correctly.

[jrray]

I'm imagining a test where the repo has many variants of the same package with a color var set to red, blue, etc.

I created a test over in #1268.

[jrray]

So at this point I think I want to just get a change merged in that stops resolvo from turning options into var requests to address our problem, and leave #1268 open to decide the fate of options. I'll rework this PR to be about adding this new test and making it pass.

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.

📢 Thoughts on this report? Let us know!

[jrray]

So basically options are not used by the solver at all now, but this field is kept around to uphold the SolverTrait contract of being able to call update_options and then see those options with get_options.

If a test is created that shows options doing something meaningful in the step solver then this field could start getting used again.