Opened 3 years ago

Closed 3 years ago

Last modified 3 years ago

#12052 closed bug (fixed)

Split ghc-boot so we have better dependency hygiene

Reported by: ezyang Owned by: bgamari
Priority: highest Milestone: 8.0.1
Component: Core Libraries Version: 8.0.1-rc4
Keywords: Cc: hvr, bgamari, RyanGlScott, ekmett
Operating System: Unknown/Multiple Architecture: Unknown/Multiple
Type of failure: None/Unknown Test Case:
Blocked By: Blocking:
Related Tickets: Differential Rev(s):
Wiki Page:

Description

At the moment, template-haskell transitively depends on bytestring. This means that any package which depends on template-haskell has its bytestring version pinned to the version that was shipped with GHC. Which is lame, because template-haskell doesn't actually use bytestring in any interesting way.

This is bad, we should split ghc-boot into two pieces, one which has the binary package database bits, and another which contains the Template Haskell bits, so we can have better dependency hygiene.

We should also have a comment on template-haskell mentioning the importance of dependency hygiene, so this doesn't happen again.

Change History (5)

comment:1 Changed 3 years ago by hvr

It's not only bytestring template-haskell started to depend on:

In GHC 7.10.3 there were the following deps:

"template-haskell-2.10.0.0" -> "base-4.8.2.0"
"template-haskell-2.10.0.0" -> "pretty-1.1.2.0"
"pretty-1.1.2.0" -> "base-4.8.2.0"
"pretty-1.1.2.0" -> "deepseq-1.4.1.1"
"pretty-1.1.2.0" -> "ghc-prim-0.4.0.0"
"deepseq-1.4.1.1" -> "array-0.5.1.0"
"deepseq-1.4.1.1" -> "base-4.8.2.0"

whereas with GHC 8.0 we have now

"template-haskell-2.11.0.0" -> "base-4.9.0.0"
"template-haskell-2.11.0.0" -> "ghc-boot-8.0.0.20160511"
"template-haskell-2.11.0.0" -> "pretty-1.1.3.3"
"pretty-1.1.3.3" -> "base-4.9.0.0"
"pretty-1.1.3.3" -> "deepseq-1.4.2.0"
"pretty-1.1.3.3" -> "ghc-prim-0.5.0.0"
"deepseq-1.4.2.0" -> "array-0.5.1.1"
"deepseq-1.4.2.0" -> "base-4.9.0.0"

"ghc-boot-8.0.0.20160511" -> "base-4.9.0.0"
"ghc-boot-8.0.0.20160511" -> "binary-0.8.3.0"
"ghc-boot-8.0.0.20160511" -> "bytestring-0.10.8.0"
"ghc-boot-8.0.0.20160511" -> "directory-1.2.6.2"
"ghc-boot-8.0.0.20160511" -> "filepath-1.4.1.0"
"binary-0.8.3.0" -> "array-0.5.1.1"
"binary-0.8.3.0" -> "base-4.9.0.0"
"binary-0.8.3.0" -> "bytestring-0.10.8.0"
"binary-0.8.3.0" -> "containers-0.5.7.1"
"directory-1.2.6.2" -> "base-4.9.0.0"
"directory-1.2.6.2" -> "filepath-1.4.1.0"
"directory-1.2.6.2" -> "time-1.6.0.1"
"directory-1.2.6.2" -> "unix-2.7.2.0"

so effectively, template-haskell now transitively adds the following dependencies (relative to GHC 7.10.3):

  • unix
  • directory
  • filepath
  • containers
  • bytestring
  • binary

this reduces a lot of flexibility from the cabal solver, and makes it impossible to use newer versions of those packages (something I did frequently in GHC 7.10.3) as soon as template-haskell enters install-plans.

comment:2 Changed 3 years ago by simonpj

I'm all for it!

comment:3 Changed 3 years ago by hvr

Milestone: 8.0.28.0.1
Owner: set to bgamari
Priority: highhighest
Version: 8.0.18.0.1-rc4

comment:4 Changed 3 years ago by simonpj

I like the direction of travel here, but I do beg for a wiki page or clearly-signposted summary somewhere that explains

  • What packages there are
  • What they contain
  • Crucially, what the thinking behind the architecture is

For example, summarising what is in ghc-boot-th, and what criteria guided that choice. Similarly ghc-prim. Etc.

There is some stuff already

comment:5 Changed 3 years ago by bgamari

Resolution: fixed
Status: newclosed
Version 0, edited 3 years ago by bgamari (next)
Note: See TracTickets for help on using tickets.