[bug] "option [...] doesn't exist" when using `[platform_requires]`

[stevenwdv]

Environment details

• Operating System+version: Linux
• Compiler+version: N/A
• Conan version: 2.1.0
• Python version: 3.10.12

Steps to reproduce

Specifying package options does not work when these are provided by [platform_requires].

• Create a conanfile with self.requires('qt/[^6.6.1]', options={'qtnetworkauth': True})
• Add to your conan profile:

  [platform_requires]
  qt/6.6.1
  

• Execute conan install
• Receive error:

  ======== Computing dependency graph ========
  ERROR: option 'qtnetworkauth' doesn't exist
  Possible options are []
  

I'd expect this to work. Am I missing something? Can I specify in [platform_requires] that I have qtnetworkauth installed? Adding qt/6.6.1:qtnetworkauth=True to that doesn't work.

Logs

======== Input profiles ========
Profile host:
[settings]
arch=x86_64
build_type=Debug
compiler=clang
compiler.cppstd=20
compiler.libcxx=libstdc++11
compiler.version=17
os=Linux
[options]
custom_dependency_opts=True
with_benchmark=True
with_client=True
with_tests=True
[platform_requires]
qt/6.6.1
[conf]
tools.build:compiler_executables={'c': 'clang', 'cpp': 'clang++'}
tools.cmake.cmaketoolchain:generator=Ninja
tools.system.package_manager:mode=check
tools.system.package_manager:tool=apt-get

Profile build:
[settings]
arch=x86_64
build_type=Debug
compiler=clang
compiler.cppstd=20
compiler.libcxx=libstdc++11
compiler.version=17
os=Linux
[platform_requires]
qt/6.6.1
[conf]
tools.build:compiler_executables={'c': 'clang', 'cpp': 'clang++'}
tools.cmake.cmaketoolchain:generator=Ninja
tools.system.package_manager:mode=check
tools.system.package_manager:tool=apt-get


======== Computing dependency graph ========
ERROR: option 'qtnetworkauth' doesn't exist
Possible options are []

[memsharded]

Hi @stevenwdv

Thanks for reporting this.

We have to think a little bit about this. The thing is that if there are options defined in recipes, it is basically impossible to use them or even check them with platform_requires. In this regard, it will be better to use a wrapper with replace_requires and let the wrapper check those options against the system installed one.

But let us have a look about this use case.

[stevenwdv]

Ah, okay. That would be a possibility. I guess that with [platform_requires] the (list of options from) the actual recipe is not available? Would it be an idea to just ignore the list of options in this case? Otherwise the uses of [platform_requires] will be quite narrow, I think.

[memsharded]

Would it be an idea to just ignore the list of options in this case? Otherwise the uses of [platform_requires] will be quite narrow, I think.

Yes, it sounds it should, but this might be a source of confusion too, users wondering why their platform provided thing is not behaving as expected, if it is not providing something they expected. So it is mostly a UX thing, maybe just warning or displaying some info regarding the options applied for that platform-requirement.

[memsharded]

I am having another look.

It seems the options={'qtnetworkauth': True} specification is kind of a "strong" contract, in the sense that it means that "I know I have a dependency on this package, and I know for sure this package defines the qtnetworkauth option, so I want it to fail if for some reason the dependency does not define the qtnetworkauth option". Which is more or less what is happening. If we define the option instead like: options={'qt*:qtnetworkauth': True} then qt* is a pattern, and it relax the assumptions that such option is mandatory to exist in the dependency and it will not fail.

After digging a bunch in the code, I think that in most cases a [replace_requires] will be better. There are just too many aspects of the dependency, that even if it is platform one, users will want to control: If it is shared or static, package_id effect, etc. Those are easy to manage with a wrapper recipe, while via [platform_requires] mostly all that information is dropped, and the integration of that platform dependency in the dependency graph will have less information to do the desired behavior.

I am not saying that we don't want to handle the current case, at least we want to fail it more clearly with a better message, or most likely, we don't want it to fail, and let the user continue at their own risk.

[memsharded]

Closed by https://github.com/conan-io/conan/pull/15804.

At the moment, options have been silently ignored. It is the responsibility of the user to know/check that the platform installed requires satisfy the graph needs. In most scenarios it is likely that a replace_requires will provide more control.