[Hackage] #382: 'cabal ghci' mode

[Hackage]

#382: 'cabal ghci' mode
---------------------------------+------------------------------------------
  Reporter:  guest               |        Owner:        
      Type:  enhancement         |       Status:  new   
  Priority:  normal              |    Milestone:        
 Component:  cabal-install tool  |      Version:        
  Severity:  major               |   Resolution:        
  Keywords:                      |   Difficulty:  normal
Ghcversion:  6.8.2               |     Platform:        
---------------------------------+------------------------------------------
Changes (by batterseapower):

 * cc: batterseapower+Cabal382 at hotmail.com (added)

Comment:

 I'm about to attach a patch I slapped together that implements this
 functionality. However, I just talked to Duncan and he says:

 {{{
 dcoutts: BSP_: btw, if possible it'd be nice to export appropriate util
 functions from the GHC module and actually implement the feature in the
 cabal program (cabal-install package)
 [23:36] dcoutts: BSP_: eg we should be able to reuse a function for
 constructing ghc command lines
 [23:36] BSP_: it wasn't clear to me what the division of responsibility
 between cabal and cabal-install was
 [23:36] dcoutts: BSP_: here's how I see it now...
 [23:36] dcoutts: the program is for the user interface, it's a tool for
 devs
 [23:37] rfh_ left the chat room.
 [23:37] dcoutts: the lib is there to provide an implementation of the
 Cabal build system interface, which is currently specified as a command
 line interface
 [23:37] thetallguy1 left the chat room. (Read error: 104 (Connection reset
 by peer))
 [23:38] BSP_: ok.. but the line is definitely blurred by the presence of
 stuff like CommandUI in the Cabal library itself
 [23:38] cognominal left the chat room. (Read error: 113 (No route to
 host))
 [23:38] dcoutts: the lib has to implement a minimal cli so that package
 build scripts can call configure, build etc
 [23:39] dcoutts: BSP_: the crucial test I think is, does the rpm build
 script need it
 [23:40] dcoutts: I mean consider a random source rpm that has scripts for
 doing the build
 [23:40] BSP_: OK
 [23:40] dcoutts: it needs to configure, build, haddock, install
 [23:40] dcoutts: it's a machine api
 [23:40] dcoutts: where as cabal ghci blah is definitely aimed at end
 users, humans
 [23:41] BSP_: right
 [23:41] BSP_: btw i've called it "cabal interactive" instead, since
 theoretically you could implement the same thing for other compilers..
 [23:42] dcoutts: BSP_: good, I do have qualms about it being too ghc
 specific
 [23:42] dcoutts: BSP_: and if people complain about the length of the
 command then we can remind them that we do provide command line
 completion!
 [23:42] BSP_:
 [23:43] dcoutts: currently only for bash, but others would be easy, the
 feature is built into cabal itself
 [23:44] thetallguy1 joined the chat room.
 [23:53] dcoutts: BSP_: if you're working on that area perhaps I can
 persuade you to do a little refactoring of the GHC module, particularly
 the way ghc command lines are constructed
 [23:54] BSP_: dcoutts: there is a lot of redundancy - but perhaps I should
 wait for your patches before changing it any further
 [23:54] dcoutts: Saizan and I started on an approach with a big GhcOptions
 record and a function renderGhcOptions :: GhcOptions -> [String]
 [23:55] dcoutts: the idea is that functions that generate or mess with
 options would use the nice structured GhcOptions values
 [23:55] dcoutts: I've got half an implementation of the idea I can send
 you
 [23:57] dcoutts: BSP_: pushing the changes now...
 [23:57] BSP_: dcoutts: cheers
 [00:00] dcoutts: BSP_: some early attempts here
 http://haskell.org/~duncan/cabal/GHC.hs
 [00:00] dcoutts: diff it vs the current ./Distribution/Simple/GHC.hs
 [00:00] pumpkin: oh wow, it's BSP on IRC!
 [00:01] dcoutts: BSP_: it's the commented out bit about GhcOptions
 [00:01] dcoutts: BSP_: so we'd make GhcOptions an instance of Monoid and
 functions like packageHsGhcOptions :: BuildInfo -> LocalBuildInfo ->
 GhcOptions
 [00:01] BSP_: pumpkin: hey there  i think i recognise your name from
 github..
 [00:02] pumpkin: yup! 'tis me
 [00:02] BSP_: dcoutts: right, i'll take a look - no promises though
 [00:02] dcoutts: BSP_: sure
 [00:02] dcoutts: BSP_: ideally it'd make it easy for you to do the ghci
 bits in an external module, in cabal-install
 [00:03] dcoutts: BSP_: ah, of course we'll have to branch cabal-install
 and have the new head branch use the head version of the Cabal library
 [00:04] dcoutts: the current stable cabal-install uses the released stable
 Cabal version
 [00:06] BSP_: ok
 }}}

 So in summary:

  * The GHC module needs a serious refactoring, perhaps using a GhcOptions
 monoid
  * The patch should be for cabal-install, not cabal
  * The second thing kind of depends on the first, so it makes sense to do
 these together

 I'll make these changes to the patch if I find the time, but if not at
 least the incomplete patch is here with the ticket.

-- 
Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/382#comment:9>
Hackage <http://haskell.org/cabal/>
Hackage: Cabal and related projects