You can clone with
No one assigned
Projects often require custom Setup.hs files which in turn may rely on Haskell packages. Those packages may in turn depend on Cabal, perhaps without being too fussy about which version of Cabal they want.
It might be useful to be able to express the idea that the Setup script itself has dependencies. Rogan Creswick suggested maybe something that looks like
Here was my musing about it: https://plus.google.com/114991347543804898741/posts/2Wpy3WWvGyH (not sure if I understood correctly, and my user claims that upping the cabal-version constraint [which should be unnecessary in that case] fixes it for them)
This appears to have come up for several projects:
To ensure that these packages are present, I sometimes abuse the build-depends for my executable, which appears to be insufficient because when a Haskell-naive user upgrades from one version of Cabal to another, you get into a kind of messy situation where the Setup.hs file wants to use one version of Cabal but it relies on the package which assumes another version of Cabal. It's the kind of thing that a Haskeller can just sort of muddle/bulldoze through, but for somebody who knows enough to type cabal install type commands but isn't otherwise a Haskeller, it can be seriously confusing.
Cabal-dev's sandbox abstraction breaks a little because we can't specify explicit Setup.hs dependencies.
Specifically, when cabal builds the Setup.hs to generate a build tool that compiles the rest of the project, it uses the user and global package databases, without acknowledging any package-db path settings/flags (which is how cabal-dev controls the sandbox). Thus, when building setup.hs, cabal is unaware of the cabal-dev sandbox. Presumably, a fix to this would also enable the Setup.hs compilation step to use a custom package database. (I could see that being a separate issue, too.)
One of the common hacks to get around the absence of setup.hs dependencies is to put those deps. in the standard build-depends for your library/executable. Cabal-install will install them first, then build setup.hs. This often works if you are not using a sandbox, because those deps go into either the user or global package db. However, this does not work with cabal-dev (it may work with virthualenv, I haven't tried).
This also introduces other potential issues, as the dependencies for Setup.hs really have no relationship to the dependencies for your actual program/library, so spurious conflicts can incorrectly cause build failures, although that's somewhat of a separate bug... (each build artifact sortof needs it's own sandbox, at least morally.)
I encourage anyone reading this to look at the summer of code ticket Erik linked too, as it outlines other benefits of explicit Setup.hs dependencies (such as sharing complex extensions to Cabal via hackage).