Copy out Distribution.Solver from cabal-install into cabal-solver

[phadej]

PoC

[23Skidoo]

Following #3965 (comment), I suggest that we use the name cabal-lib-solver instead of cabal-solver. Then eventually we will have:

• cabal-lib for the pure parts of current lib:Cabal
• cabal-lib-build for the build system bits
• cabal-lib-solver for the cabal-install's solver
• cabal for what is currently cabal-install

[phadej]

To clarify this PoC, it took me 15 minutes to assemble. I'd really like to see a single downstream which would use this, or some other part of cabal-install (they can do it too, add cabal-lib-solver as an internal lib). We have bad experience where people asked for the feature, but then didn't use it - yet there's a maintenance burden for us.

So I'd really like to see realistic experiments where this - cabal-lib-solver, or refactored out Types (for config reading/writing) or something else is used for great benefit outside cabal-install.

I want to see existential motivation, not vague "it would be nice".

To be clear: I don't think this is good idea either. Public multi-libs is better idea, when cabal-install will be able to use them for itself.

[23Skidoo]

It'll be a while until we can use multilibs, the cabal-lib-* split can be done in 3.0.

[phadej]

Isn't splitting Cabal something we can only reasonably do when there are no need to use Custom setups?

…

Sent from my iPhone

On 1 Aug 2018, at 2.23, Mikhail Glushenkov ***@***.***> wrote: Following #3965 (comment), I suggest that we use the name cabal-lib-solver instead of cabal-solver. Then eventually we will have: cabal-lib for the pure parts of current lib:Cabal cabal-lib-build for the build system bits cabal-lib-solver for the cabal-install's solver cabal for what is currently cabal-install — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub, or mute the thread.

[quasicomputational]

On concrete use-cases, I have a couple of day-one candidates:

• Implementing something like Stack's pvp-bounds on top of freeze files: adding constraints to the .cabal files based on the freeze files' constraints, on the basis that then you're only declaring compatibility with what's been actually tested. This needs to be able to read the freeze files. I actually have a prototype of this tool (it's not complicated), but I don't know if that'll meet the "great benefit" threshold.

• Stack would like to use the solver. Use cabal-install dependency-solver as a library commercialhaskell/stack#1615 is the bug over there about it.

• There are at least two efforts to convert cabal.project to Nix derivations. Note that that's first one is already using cabal-install as a library.

Less concretely or with less great benefit:

• In a multi-package project, if some of the packages don't work with some GHC versions but you'd like to test the rest, you need multiple .project files. I'm currently generating them with ad-hoc code but I'd like to use the proper renderer.

• Any static analysis tool would benefit from being able to read cabal.project and discover all the packages in the project. Imagine pointing hlint at your cabal.project instead of having to direct it to each package. Along the same lines, IDE integration: discovering local packages so that jump-to-definition can work without manual set-up.

[23Skidoo]

Re: packages with custom setups, they must update setup-depends anyway for the new release, and we can also add a compatibility shim lib:Cabal that re-exports cabal-lib and cabal-lib-build with a deprecation warning.

[hvr]

@quasicomputational

• your first example is something that plan.json was designed for; I have similar tooling, and I'm happy to use plan.json for that; using solver-as-a-library would be a lot more effort.
• We've had bad experience with requests coming from Stack dev; also I don't see why we should actively support a competing tool which from day has aimed to replace cabal, not to mention the personal attacks originating from Stack devs towards Cabal devs.
• This leaves the Nix projects; but here I'd ask the same as for the first item: why can't we use plan.json for that? What would it take to use the plan.json interface? What can you do with a solver-as-library you can't do by invoking cabal new-build? How can we improve cabal's CLI to reduce the incentive to abuse cabal-install-as-a-library?

Also, we have #2771 on the roadmap; which is intended in combination with plan.json as the designated way to interface to exe:cabal and its facilities.

Parsing the cabal.project file doesn't require to have the full-blown parser machinery & types from cabal; haskell-ci is evidence to that, and for haskell-ci I would rather want a "lightweight" cabal.project parser, rather than the heavy one in cabal.

if some of the packages don't work with some GHC versions but you'd like to test the rest, you need multiple .project files.

Currently, but there's some ideas on the table to improve this; but they certainly don't require to be able to "render" cabal.project files; what you're doing now is merely a stopgap solution, so hardly a long-term justification.

[phadej]

if some of the packages don't work with some GHC versions but you'd like to test the rest, you need multiple .project files.

https://github.com/phadej/darkmatter/blob/master/src/DarkMatter.hs renders
https://github.com/phadej/acme-kmett/blob/master/cabal.darkmatter into

• https://github.com/phadej/acme-kmett/blob/master/cabal.7.6.3.project
• https://github.com/phadej/acme-kmett/blob/master/cabal.7.8.4.project
• https://github.com/phadej/acme-kmett/blob/master/cabal.8.2.2.project
• ...

It's "ad-hoc" approach, but very robust one. cabal-install would use something very similar.

EDIT I don't remember why I didn't yet made a PR to Cabal to add prettyFields.

EDIT2: Note that darkmatter also generates Makefile to work with all generated projects (e.g. build all of them)

[phadej]

We have .pp setup so we can internal libs for starters.