new-build produces bad error message on missing cabal.project

[BardurArantsson]

If the cabal.project file is missing cabal new-build produces the rather opaque error message

BadPackageLocations [BadLocGlobEmptyMatch "./*.cabal"]

It should probably print something more informative. :)

[BardurArantsson]

Oh, and the exact cabal-install version I'm running is commit b7b666e

[dcoutts]

Just need to add displayException method to the instance Exception BadPackageLocations to give a nice human readable message.

[BardurArantsson]

Sigh... I suppose the labels mean that I really should do this...? I'm just (semi-)joking, I'd be happy to, given the hint.

Aside: Why are we relying on overriding defaults in this manner? Shouldn't we just have a (huge) sum type for every single error that Cabal/cabal-install can show and then be forced to implement a human-readable error message? (I'm sure I'm doing a "couldn't we just..." type thing here, but...)

(Assigning to self in the hope of finally starting to contribute to Cabal again.)

[ezyang]

@BardurArantsson, if you want to rip out and rewrite all of the error reporting code in cabal-install, I will support the endeavor. But I'd want to see some sort of style guideline come out of it, saying, "This is how we deal with error reporting in cabal-install" (and ideally also, "here's why"). So that if I'm a not-paying-very-much-attention developer and I need to add an error, I know what to do, it is not hard to do "the right thing".

[alanz]

Ping @BardurArantsson: Are you still working on this? I'm looking for a trivial getting started issue.

[BardurArantsson]

No, it fell through the cracks. Feel free to take a swing at it.

[dcoutts]

Could someone check what this does now (since #3774 added proper messages), and suggest changes to the error message that would make it more appropriate for the situation where there is no explicit cabal.project file. The current message is written assuming there is one and the user groks this.

If someone (@alanz ?) wants to look at this, you'd want to extend the plumbing so that the exception we throw contains info on whether or not the project config was from an implicit project file on an explicit one (perhaps even with file path location). This would probably require extending the ProjectConfig itself with a field that says if it originated from a implicit or explicit cabal.project (again, perhaps with file path).

[ezyang]

Same old:

ezyang@sabre:~/Dev/labs$ cabal-shake new-build
BadPackageLocations [BadLocGlobEmptyMatch "./*.cabal"]

[dcoutts]

@ezyang what is cabal-shake doing? Does its top level exception handler use show or displayException ?

[ezyang]

Oh, the alias was pointing at an old binary. OK this is fixed in HEAD.