[GHC] #15726: Don't include Haskeline (and others) in the global package DB

#15726: Don't include Haskeline (and others) in the global package DB -------------------------------------+------------------------------------- Reporter: judah | Owner: (none) Type: feature | Status: new request | Priority: normal | Milestone: Component: Build System | Version: 8.6.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- GHC installations include `haskeline` in their global DB, as well as its dependencies (currently: `stm` and `terminfo`). However, Haskeline isn't a dependency of the `ghc` library, so that shouldn't be necessary. Originally suggested by hvr here, in response to needing to pull `stm` into the global DB: https://github.com/judah/haskeline/pull/61#issuecomment-294878302 This change would let Haskeline add dependencies more easily. See in particular the pending PR to depend on the "exceptions" package: https://github.com/judah/haskeline/pull/97 -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/15726 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

#15726: Don't include Haskeline (and others) in the global package DB -------------------------------------+------------------------------------- Reporter: judah | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: Build System | Version: 8.6.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): Indeed this sounds reasonable to me. The only possible issue is that it would also be no longer possible to link against the `ghci` library that ships with GHC (since it depends upon `haskeline`). However, I suspect this won't be a problem since GHC is more-or-less a normal Haskell package which `Cabal` should be able to install on its own. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/15726#comment:1 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

The only possible issue is that it would also be no longer possible to
#15726: Don't include Haskeline (and others) in the global package DB -------------------------------------+------------------------------------- Reporter: judah | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: Build System | Version: 8.6.1 (make) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by hvr): Replying to [comment:1 bgamari]: link against the `ghci` library that ships with GHC (since it depends upon `haskeline`). Are you ''sure'' the original issue why we started properly registering GHCi's dependencies around GHC 7.8 has been dealt with? Otherwise this will just throw us back to square one with the bugs/issues we had pre-7.8. ---- Replying to [ticket:15726 judah]:
Originally suggested by hvr here
Note also that my suggestion/comment hinged on the condition that we
invest some time during the GHC 8.3.x dev cycle to figure out a way to decouple haskeline/terminfo from GHC's global pkg-db again so that haskeline can pick up new libraries (within reason) more easily
but we haven't done this yet; hence we cannot deal with a new `exceptions` yet without dragging in `execptions` as well as its extra transitive dependencies into GHC's source-tree... :-/ -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/15726#comment:3 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

#15726: Don't include Haskeline (and others) in the global package DB -------------------------------------+------------------------------------- Reporter: judah | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: Build System | Version: 8.6.1 (make) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): I have emailed Judah about this. Hopefully he'll be able to cut another minor release without the `exceptions` dependency for 8.8. Then I suppose we'll need to figure out how to make progress on this ticket for 8.10.
Are you sure the original issue why we started properly registering GHCi's dependencies around GHC 7.8 has been dealt with? Otherwise this will just throw us back to square one with the bugs/issues we had pre-7.8.
Not at all; can you refresh our memories on what those issues were? -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/15726#comment:4 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

#15726: Don't include Haskeline (and others) in the global package DB -------------------------------------+------------------------------------- Reporter: judah | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: Build System | Version: 8.6.1 (make) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by hvr): Replying to [comment:4 bgamari]:
Are you sure the original issue why we started properly registering GHCi's dependencies around GHC 7.8 has been dealt with? Otherwise this will just throw us back to square one with the bugs/issues we had pre-7.8.
Not at all; can you refresh our memories on what those issues were?
comment:ticket:8919:17 gives a summary of the issues involved which eventually lead to 4caadb7cbee5c176abb99df25c4cc1657ae57f40; and you can find some potential approaches to addressing the issue mentioned in the surrounding discussion. Note however, that `lib:Cabal` has also slowly been acquiring more dependencies, such as `lib:mtl`, `lib:text` or `lib:parsec` (and I've recently realised that the option of not bundling `lib:Cabal` with GHC is not feasible anymore for reasons related to catch-22s in the bootstrapping process). -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/15726#comment:5 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler
participants (1)
-
GHC