cabal gen-bounds: Consume (multiple) build plans?

[nomeata]

I’d like to automate the managing of my build dependencies more, and cabal gen-bounds sounds like it should be an important tool in the process.

However, my projects usually support a range of builds (e.g. different GHC versions), and simply generating the bounds based on one solver results is not going to work.

I could imagine that cabal gen-bounds could read in multiple build plans (e.g. the plan.json produced when building the project) and generating the appropriate dependencies (maybe in ^>= { 1.2.3, 3.4.5 } form) from the union of these build plans.

(Also see related discussion in https://discourse.haskell.org/t/dependency-version-bounds-are-a-lie/5522/17?u=nomeata)

[jneira]

Hi, thanks for the suggestion. There are other issues about gen-bounds which could be related:

• gen-bounds does not work in multiprojects #7504: if gen-bounds were project aware it could honour cabal.project (and alternative project files) with different values affecting directly the solver: with-compiler, constraints, etc
• Uniform handling of -w[ith-compiler] #4956: if gen-bound would accept --with-compiler flag you could have different bounds for each one. This one is subsumed in the first one, more generic

From my tests cabal gen-bounds uses the ghc in PATH so a possible workaround for get bounds for each ghc could be set them as the default ghc:

PS D:\dev\ws\haskell\cabal-test> ghcup set ghc 9.4.2
.......
PS D:\dev\ws\haskell\cabal-test> cabal gen-bounds
.......
bytestring       >= 0.11.3 && < 0.12,
network          >= 3.1.2 && < 3.2,
process          >= 1.6.15 && < 1.7,
text             >= 2.0.1 && < 2.1,
PS D:\dev\ws\haskell\cabal-test> ghcup set ghc 8.10.7
................
PS D:\dev\ws\haskell\cabal-test> cabal gen-bounds -v0
................
bytestring       >= 0.10.12 && < 0.11,
network          >= 3.1.2 && < 3.2,
process          >= 1.6.13 && < 1.7,
text             >= 1.2.4 && < 1.3,

[nomeata]

I started hacking on my own tool (https://github.com/nomeata/cabal-plan-bounds), see it in action at
https://discourse.haskell.org/t/dependency-version-bounds-are-a-lie/5522/22?u=nomeata

But I’ll happily discard that once this is “officially” supported.

(I actually think it’s advantagous if gen-bounds reads a plan, rather than tries to resolve it itself. This way you can have different CI Jobs for different configurations, and collect the plans in the end, without for example having to install all relevant versions of GHC in the same job. But maybe that’s premature optimization.)

[nomeata]

It looks like the wrong issue was closed by that commit. Can it be reopened?

[jneira]

Well, read the cabal plan outut is more flexible and the way to go for an external tool. However there is no cabal command handling explicitly that output afaik. They consume it implicitly, triggering its generation if needed (or on the fly, like gen-bounds).
I guess it was considered an implementaion detail which should not be leaked to final users.

That design could be changed of course, but it would have broader implications (why not use it explicitly in more places?)