ifPresentInBuildEnv limitation for package requirements

[jrray]

A package that depends on a package conditionally, as in:

pkg: example/1.0.0
build:
  options:
    - pkg: dep1
  variants:
    - { "dep2": "1.0.0" }
    - {}
install:
  requirements:
    - pkg: dep2
      fromBuildEnv: true
      ifPresentInBuildEnv: true

The second variant doesn't depend on dep2 and the package author does not want that variant build of example to have an install requirement on it.

The problem lurks in if dep1 also has a requirement on dep2. If so, then dep2 will in fact be in the build environment so ifPresentInBuildEnv is triggered.

It's true that users of example will also end up with dep2 in the env through that transitive requirement, but example shouldn't get "blamed" for requiring it.

The only option the package author has right now is to create separate recipe files.

Short of an overhaul of the recipe spec, one idea is to have an additional toggle to specify that the package must be requested by the defining package, not just present in the build env. Since we track requestors this should be an easy thing to implement.

[rydrman]

From the meeting today:

• either a new top level booolean, or maybe better is to have different values (not just true/false) that are accepted into the existing ifPresentInBuildEnv