Add a `--trust-pvp` flag

[sellout]

The matrix could be reduced if we trust that dependencies follow PVP.

Here are some potential simplifications, based on the examples in the README:

bytestring│0.9.0.x    0.9.1.0    0.9
──────────┼────────────────────────▶
          │
──────────┼────────────────────────▶
          │no plan    no plan    no

In this case, you still needed to build every version, but none of them resulted in a plan, so you can summarize to 0.9.0.x (maybe the linked info should be for the highest version in the set, which should have the widest bounds).

  COMPILER│ghc-9.8.4  ghc-9.12.2
──────────┼─────────────────────
bytestring│
──────────┼─────────────────────
^>=0.11.4 ▼build ok   build ok

In this case, you can stop building with GHC 9.8.4 after 0.11.4.0, but need to keep building with 9.12.2 until 0.11.5.3 (but if there’s a 0.11.5.4 or a 0.11.6.0, you don’t have to build them at all because PVP tells you that there should be a plan and they should build ok).

           COMPILER│ghc-9.8.4  ghc-9.12.2
───────────────────┼─────────────────────
bytestring text    │
───────────────────┼─────────────────────
^>=0.11.5          │build ok   build ok
              2.0  │no plan    no plan
           ^>=2.0.1│build ok   no plan

Here it summarizes to the lowest version that found some plan. So it shows both as build ok for bytestring ^>=0.11.5, even though one of them was ok at 0.11.5.0 and the other not until 0.11.5.3.

Similarly, even though text 2.0.2 didn’t find a plan for GHC 9.8.4 – it doesn’t affect the bounds we want to use. However, it can’t summarize to ^>=2.0, because if something changes in future and a plan becomes viable, PVP doesn’t promise that code that compiled with text 2.0.1 will compile with text 2.0.

  COMPILER│ghc-9.2.8  ghc-9.2.8
  tar     │^>=0.6.0   ^>=0.7.0
──────────┼─────────────────────
directory │
──────────┼─────────────────────
   1.3.5.0▲no plan    no plan
^>=1.3.6  │build ok   build fail
^>=1.3.8  │build ok   build ok

Here is why --trust-pvp should be an opt-in flag. It will likely¹ miss the tar bug you call out in the README. But since you can’t put interdependent ranges in cabal files, you still need to make the decision to either not support tar ^>=0.7.0 or not support directory 1.3.[6,7] in your package.

But, personally, this is where I’m willing to save some effort and not try to solve upstream issues in my build matrix.

Maybe there could be --trust-pvp --no-trust-pvp=tar to say “some packages don’t really follow PVP, so be careful with them”?

Footnotes

1. Just “likely”, because --trust-pvp could induce a binary search for the bound, where tar 0.6.4 + directory 1.3.7.0 is tried before any tar 0.6.[1,3] + directory 1.3.[6,7] version, and the failure drops those combinations from the possibility set. ↩

[mniip]

I don't think I understood what exactly you're suggesting here.

• Do you want to be able to specify a build matrix where one alternative has cabal build --constraint "tar ^>=0.6" and another has cabal build --constraint "tar ^>=0.7"?
  You can already sort of do that with --custom-options.
• Do you want to be able to automatically generate such matrices based on what tar versions exist?
• Or do you want the matrix to actually include alternatives for each tar ==0.6.* version, and have a collapsed view that only displays them as one row/column?
  • In that case do you want later versions to be skipped if an earlier version succeeds?

[sellout]

Sorry, I seem to have left out part of what I intended to write, in the excitement of putting those examples together!

Basically the last one. And yes, skipping later ones. E.g., if a library has versions 0.[0-9].[0-9].[0-9] (which would be a lot of releases), I’d like to see just ten¹ entries in the matrix: ^>=0.0._, ^>=0.1._, etc. With each _ replaced by “lowest”² minor version that succeeded.

Footnotes

1. Maybe more then 10, because if we find 0.0.3 as the lowest version that works, we must have tried 0.0.2, so it would be go to include that to know why 0.0.3 is our bound. ↩

2. Since this is about trusting PVP, I’m happy with a binary search – say 0.0.5 gets attempted first, then either 0.0.3 or 0.0.8 depending on whether that one succeeds, etc. So, if 0.0.0 works and 0.0.3 works, but 0.0.1 and 0.0.2 are broken³, then we might never discover that 0.0.0 works, but that’s fine. ↩

3. Hopefully if they’ve violated PVP, those versions would be deprecated on Hackage, so the binary search would skip them. ↩

[mniip]

Note that binary search as a concept only works in 1 dimension. Finding a pareto front in higher dimensions is computationally pretty tricky.

I had planned some features where that would require short-circuiting builds, but only a simple linear fashion, nothing as advanced as binary search.