Imports in complex Setup.hs -- should we encourage/require PackageImports?

Several libraries (notably Pandoc and Gtk2hs) have very complex Setup.hs scripts, which import several external libraries. In my experience, these imports are very fragile, because Cabal does not enforce package visibility in Setup.hs. For example, a Setup.hs that imports Control.Monad.Trans will break if "monads-tf" is installed, and one that imports System.FilePath will break if "system-filepath" is installed. My typical solution when this happens is to manually tweak the GHC package database before installing, but this is annoying and does not help other users. Based on a ticket in Cabal's Trac < http://hackage.haskell.org/trac/hackage/ticket/326 >, custom Setup.hs scripts are discouraged by the Cabal developers. I assume this means there will not be much development effort put towards an integrated solution (such as using -hide-all-packages and build-depends: when compiling Setup.hs). A possible solution is to ask developers with complex Setup.hs requirements to use the PackageImports language extension when importing external libraries. However, this places a burden on such developers, and I don't know if it's portable to non-GHC compilers. It would also need an analysis of currently published Hackage packages to see which have such scripts. Any ideas/comments? Has anyone by chance found a good solution to this?

On Mon, May 23, 2011 at 3:08 PM, John Millikin
Any ideas/comments? Has anyone by chance found a good solution to this?
I suggested a SoC project to implement a dependencies section for Setup.hs: http://hackage.haskell.org/trac/summer-of-code/ticket/1602 I wasn't aware of PackageImports -- I personally think that it's better to move the dependencies into a single place to reduce conflicts and to make it easier to identify the dependencies, but I'm open to arguments to the contrary :) In any case, this has frustrated and bitten me numerous times. I frequently want to share code between setup.hs files and I know of no clean way to do so. (apologies if this is delivered twice.. I got a mailer daemon failure the first time, so I'm manually entering the address now...) --Rogan
participants (2)
-
John Millikin
-
Rogan Creswick