Bugfix: add test to illustate failure when options differ between requires and build requires

[SSE4]

we have found conan client may fail if options are different between requirements and build requirements:
conan-io/conan-center-index#7747 (comment)

I think the cause of the issue is:

conan/conans/client/graph/graph_binaries.py

Line 311 in 6d7642d

conanfile.build_requires_options = conanfile.options.values

Changelog: omit
Docs: omit

• Refer to the issue that supports this Pull Request.
• If the issue has missing info, explain the purpose/use case/pain/need that covers this Pull Request.
• I've read the Contributing guide.
• I've followed the PEP8 style guides for Python code.
• I've opened another PR in the Conan docs repo to the develop branch, documenting this one.

^{Note: By default this PR will skip the slower tests and will use a limited set of python versions. Check here how to increase the testing level by writing some tags in the current PR body text.}

[SSE4]

checked develop2 locally, it passes the same test, so no issue with v2

[SSE4]

I was doing a git bisect and identified a commit fixing an issue in develop2:
6a5bd19
the commit is quite big, and as it was squashed, so I can't say the exact line fixed it.
still, it identifies the only commit to be back-ported into develop to get the fix.

UPD: indeed, it removes the line doing conanfile.build_requires_options = conanfile.options.values.
@memsharded do you think this particular change can be isolated/extracted and back-ported into develop1?

[memsharded]

I have checked this for a second time (sorry for the delay, I checked it some time ago, but didn't finalize report), it really looks like it is impossible to backport any of that from 2.0 to 1.X without breaking.

[jgsogo]

For anyone arriving at this issue, let's provide a workaround for Conan v1 (see below).

Description of the scenario

If the same recipe name is used in host and build contexts, but those contexts are using different recipes with different options (number or name, not values), for example:

name/v1/conanfile.py

class Recipe(ConanFile):
   name = "name"
   version = "v1"

   options = {
      "opt1": [True, False]
   }

name/v2/conanfile.py

class Recipe(ConanFile):
   name = "name"
   version = "v2"

   options = {
      "opt2": [True, False]
   }

And the consumer:

conanfile.txt

[requires]
name/v1

[build_requires]
name/v2

Conan v1 will compute only one set of options and it will try to apply the same set to both recipes. Conan will raise an error saying that some of those options cannot be found in the recipe (indeed, opt2 is not available in name/v1).

Workaround for Conan v1

The easiest way to workaround this issue is to match the list of options between the two versions, by adding dummy (unused) options to their recipes:

name/v1/conanfile.py

class Recipe(ConanFile):
   name = "name"
   version = "v1"

   options = {
      "opt1": [True, False],
      "opt2": [True, False],  # <-- not used in this version
   }
   
   def package_id(self):
      del self.options.opt2  # <-- removed from package-id computation

name/v2/conanfile.py

class Recipe(ConanFile):
   name = "name"
   version = "v2"

   options = {
      "opt1": [True, False],  # <-- not used in this version
      "opt2": [True, False]
   }
   
   def package_id(self):
      del self.options.opt1  # <-- removed from package-id computation

[memsharded]

It will not be possible to provide a fix for 1.X, and this will need to wait until 2.0 for a solution.
Hopefully the workaround above is enough in the meantime. Thanks all for the feedback.