Scenarios with ambigious solutions with respect to the spec?

[notatallshaw]

This is the scenario: https://github.com/astral-sh/packse/blob/0.3.12/scenarios/prereleases.json#L320

It's listed as:

"expected": {
    "satisfiable": false,
    "explanation": "Since the user did not explicitly opt-in to a prerelease, it cannot be selected."
}

But there are many ways to interpret the spec, especially given the spec does not explicitly consider resolution. Currently pip resolves this scenario with: a==1.0.0 b==1.0.0 c==2.0.0b1.

What is packse's intent here? To set tests against the design principles of uv or against the spec?

Might it worth "expected" being a list of possible options when facing ambigious scenarios like this?

[zanieb]

Yeah this is tough...

Ideally we'd test against the specification rather than uv's design principles. I'm not sure what we should do when the spec is ambiguous. Ideally the spec wouldn't be ambiguous so maybe we should propose changes.

I worry about allowing multiple expected outcomes, it sounds complicated but perhaps that's the right solution. We could also consider some sort of "feature flag" style annotation for scenarios outcome where, for example, we have two pre-release modes explicit and implicit and the scenario is tagged as such so it can be filtered out of implementations based on the mode they support.

[notatallshaw]

I would be comfortable with a mode that meant something like "allow package to be marked prerelease by transitive dependency" and when False then pip wouldn't test against it.