Associate a message with buildable: False

[michaelpj]

From what I've observed, people use buildable: False to mean "don't even try to make a plan with this in, it really won't work I promise". But it can be helpful for the user to know why this statement is being made. For example:

• if os(windows) buildable: False -> "This package cannot be built on windows"
• if impl(ghc > 9.2) buildable: False -> "This package does not support GHC greater than 9.2"
• if os(windows) && impl(ghc > 9.2) buildable: False -> "There's a specific issue on Windows that means we can't support this"

At the moment, all of these show up in the solver as something like library is not buildable in the current environment. It would be neat if we were somehow able to attache a message saying why the library is not buildable that could be shown at this point.

This is useful because it would make it much clearer for downstream people what to do. For example, I had a colleague ask my why my library was showing up as not buildable in this way, and I had to tell him myself that it meant "not buildable with GHC 8.10". It would be nice if the computer could have told him.

[ulysses4ever]

Sounds reasonable, thank you for taking the time to submit the proposal!

Judging by the examples you show, there’s no big reason to support the message (and therefore change the Cabal file format, which many people would be cautious about): it looks like just printing out the condition itself would explain the situation just as well. Or do you think more creative messages providing the reason for a failure would be in high enough demand?

[michaelpj]

Well, it's not like the syntax of cabal files mandates that buildable: False be exactly nested inside a conditional. So I'm not sure that's viable in general.

e.g. you can have stuff like

if os(windows)
  if impl (ghc >9.2)
     build-depends: whatever
  else
     buildable: False

So the dumbest thing I could think of was a message.

That said... thinking about this makes me wish I had a way to annotate things that will block the solver in general. Imagine being able to annotate bounds so that if they block a plan you see that in the solver log. That could be quite handy:

build-depends:
   some < 1.2 "some-1.2 removes an instance we need"
   , hashable < 3 "speculative upper bound"

Anyway, this is mostly idle brainstorming and I have no idea what the syntax would look like or whether it would actually be possible to propagate it around.

[grayjay]

#3072 is related, especially the "fail" feature mentioned in #3072 (comment).