support boolean literals in package dependencies

[v-gb]

Desired Behavior

In the depends fields of package stanzas of dune-project files, I'd like to be able to say true and false in places where variables like with-dev-setup are currently allowed. Currently, AFAICT, this is not possible (although you can write :false to get a variable named false, which I suppose kind of works, but is weird).

The context is my project vendors library L, and thus my dune-project needs to incorporate library L's dune-project dependencies. But L's dune-project contains references to with-dev-setup that I claim should always be off (because I'm not vendoring the tests, but I may use with-dev-setup for my own purpose). Obviously, I could manually simplify any boolean away, but the inclusion of L's dependency is done with a script.

Currently, I'm using (= 1 0) when I need false, but opam maintainers are not necessarily happy about that.

Example

I'd like to be able to write this sort of things in a dune-project:

(package
  (depends
   (alcotest
     (and
      false ;; <---
      (>= 1.3.0)))

[rgrinberg]

Do we accept things like (and pkg1 pkg2)? If we do, we'll need to escape false and true as :false or :true.

[gridbugs]

This is related to #9464. That issue is about boolean literals in lockfiles but it has the same problem as adding them to package filters: barewords in dune are implicitly quoted, so "false" and false are equivalent and dune treats them as strings.

The package filter dsl is defined at https://github.com/ocaml/dune/blob/main/src/dune_lang/package_constraint.mli#L9-L26. It's pretty obvious how that would need to change to support boolean literals. The only problem is how to unquote/escape them so they don't get treated like strings or variable names.

Do we accept things like (and pkg1 pkg2)? If we do, we'll need to escape false and true as :false or :true.

No, the only things that can be passed to and/or are boolean expressions, which can be variables like :with-test or the result of applying unary and binary boolean ops, or the result of another conjunction (and/or). Strings are not allowed in this position. We could consider allowing strings in this position and making it an error if the string is neither "true" nor "false".