search

berberman / arch-hs

Distribute hackage packages to archlinux
MIT License
19 stars 4 forks source link

Use cabal to resolve dependencies #33

Open poscat0x04 opened 3 years ago

poscat0x04 commented 3 years ago

When you call cabal configure inside a cabal project, cabal will automatically resolve dependencies and produce a file representing the build plan called plan.json under the directory dist-newstyle/cache. There are some advantages to using plan.json over the current method:

  1. No need to reimplement dependency resolution
  2. cabal resolves dependencies separately for different components (library, sub-libraries, executables, tests, benchmarks)
berberman commented 3 years ago

Haven't seen you for a long time >_<

Actually, I didn't aware that cabal can produce plan.json -- which describes the dependency information, and can be operated by cabal-plan -- until a while after I finished the main part of arch-hs. It's good to use an existing solution, instead of reimplementing the entire dependency resolution. But noticed that cabal solver is a internal part of cabal-install, which does not provide publid API. This would let arch-hs depends on cabal-install, which seems not quite reasonable. Moreover, arch-hs currently does not consider the version constraint of packages during the dependency resolution, so it does something like "collecting" dependencies, rather than "resolving" dependencies. This does have advantages. According to the Arch Linux packaging principle, we always follow the latest version of packages. If a set of packages are not buildable due to the version bounds or compatibility, we should fix those problematic packages before distribute them. Thus, conventional SAT solver does not make a lot of sense here. BTW, arch-hs resolves five types of components as well, then makes libraries, sub-libraries, and executables become depends, tests become makedepends.

berberman commented 3 years ago

arch-hs works fine now, but a full-featured SAT solver can make contribution to checking the consistency of target packages, i.e. it would warn us if there is no available build plan, so that we can know some packages need to be fixed before we actually build them. I'm glad if you could help me refactor the project.

poscat0x04 commented 3 years ago

True. I have been working on a rewrite of cabal2nix (that adds many features) recently. I stumbled into your repo while searching for a good way of doing dependency resolution. After some research, my conclusion is that it's just too much of a hassle to reimplement cabal-install's solver. That was just my two cents :)