On Tue, Aug 26, 2008 at 2:22 PM, Duncan Coutts wrote:

So when ghc finds that one of your modules needs to import something that is not in one of the given packages it says that it's in another package that is 'hidden'. Of course it's only hidden because Cabal told ghc to hide them.

Yes, it is one of those unfortunate error messages that says "I know what the problem is *and* how to fix it, but I'm not going to". ;-) Cheers, Dougal

...

...

So when ghc finds that one of your modules needs to import something that is not in one of the given packages it says that it's in another package that is 'hidden'. Of course it's only hidden because Cabal told ghc to hide them.

Yes, it is one of those unfortunate error messages that says "I know what the problem is *and* how to fix it, but I'm not going to". ;-)

Actually it's more like: "I know what the problem is but I cannot fix it. He knows how to fix it, but doesn't know there's a problem!" :-)

GHC knows what the problem is but it's just following orders. Cabal gave the orders but doesn't know there is a problem.

Since you said "don't hold your breath for Cabal's dependencies": Cabal doesn't have to pass on ghc's messages uninterpreted. That's a lot like implementing a map as a list and complaining about empty list instead of element not found. Cabal is the interface here, ghc is the tool. The interface shouldn't just pass instructions to the tool, it should also interpret and present the tool's responses. As suggested in this thread: http://www.haskell.org/pipermail/cabal-devel/2007-December/001497.html http://www.haskell.org/pipermail/cabal-devel/2007-December/001499.html Hmm, the archive failed to decode the code sketch attached to the last message there (which demonstrated that some basic help could be hacked up as a simple pattern->message script wrapping cabal), so I attach the old code again for reference. Claus

...

Cabal doesn't have to pass on ghc's messages uninterpreted. That's a lot like implementing a map as a list and complaining about empty list instead of element not found.

I see what you're saying, but in practise it's just not possible. GHC can return a non-zero exit code for a multitude of reasons (most of which will be genuine errors in your source code). It's just not practical to parse the error messages that ghc produces and try and reinterpret them. I fear it'd quite easy to introduce more problems than are solved this way.

Introducing more problems is quite possible, though changes in error messages should mostly mean that the rules won't trigger and no helpful explanation is given. And even that could be cured by having the collection of rules updateable, separately from Cabal itself. And when the forthcoming next base split, and extensible exceptions, and Cabal Api changes, and .. are going to introduce new break points, updating the rules will offer help for those breakages, too. Given the shakiness of this simplistic approach, one might not want to enable it by default, but what about an option '--explain' and a hint if things go wrong: "if you would like help interpreting common Cabal package issues, you can try repeating your command with our experimental --explain option". What I don't understand are your "in practise it's just not possible" and "It's just not practical to parse the error messages that ghc produces and try and reinterpret them". I assume you've tried the code I first sent some 9 months ago, and again this week, and found that it wouldn't work for some reasons,but you haven't told me those reasons yet.

If one wanted to take this approach you'd need to have some mode where error messages are produced in a machine readable format (which is of course doable if you write a client using the ghc api).

A quicker hack would be to change ghcs error message in this circumstance, where the -hide-all-packages flag is given.

One would want to have such support depend on an extra option, '--errors-in-xml' or something equally scary, but I'm afraid the extra readability/stability would be mostly illusionary. We're talking about "good enough" hacks to cover "not quite right" left-overs from too much instability in the Haskell tool chains - as long as the instabilities remain, there is no "perfect" solution.

Given our limited amount of volunteer developer time I think it's much better investing it in proper solutions.

How many times over the last 9 months have you had to explain what a script could have told your Cabal users? And how many more Cabal/Haskell users have been scared away in that time, without even raising their build problems on any of the lists? "Proper" solutions are alright when we have them. "Good enough" but hacky is much better than nothing. With an '--explain' option and a collection of rules, you'd have to explain every error condition just once, then update the rules/explanations, and let Cabal repeat the explanation whenever needed. If those canned explanations don't work, users can still ask here. Claus

thank you very much for the explanation! i take that in this case, the error is in the cabal, which does not list the required package. andrew On Tue, 2008-08-26 at 15:09 +0100, Duncan Coutts wrote:

On Tue, 2008-08-26 at 14:30 +0100, Dougal Stanton wrote:

...

On Tue, Aug 26, 2008 at 2:22 PM, Duncan Coutts wrote:

...

So when ghc finds that one of your modules needs to import something that is not in one of the given packages it says that it's in another package that is 'hidden'. Of course it's only hidden because Cabal told ghc to hide them.

Yes, it is one of those unfortunate error messages that says "I know what the problem is *and* how to fix it, but I'm not going to". ;-)

Actually it's more like: "I know what the problem is but I cannot fix it. He knows how to fix it, but doesn't know there's a problem!" :-)

GHC knows what the problem is but it's just following orders. Cabal gave the orders but doesn't know there is a problem.

That's why it'll be fixed when Cabal does the dep chasing rather than delegating that to ghc --make. Cabal will then be able to either just pull in the (probably) right packages, or report the problem using the language of the problem domain and not the implementation.

Duncan