[bug] default_options does raise any error/warn if a package is not in reqiures

[ashley-b]

Describe the bug

Conan version 2.11.0

Apologies in advance if this is not a bug, but just a limitation.

In a small project I'm working on, I found one of the options I was setting in the configure(self) method was being ignore when I ran conan graph info, I discovered the package name I was using was misspelt. I corrected this and that fixed it

But I think Conan should be able to warn or error if the package or option is never referenced

How to reproduce it

conanfile.txt

[layout]
cmake_layout

[options]
recipe_that_does_not_exist/*:with_bar=true
zlib/*:option_that_does_not_exist=true

[requires]
zlib/1.2.13

[memsharded]

Hi @ashley-b

Thanks for your question.
This is expected behavior, not a bug.
As long as the option package pattern is a pattern, it is allowed to not fail or report if the package does not report the option. Using an exact match fails:

$ conan install --requires=zlib/1.3.1 -o zlib/1.3.1:dontexist=3

======== Input profiles ========
Profile host:
[settings]
...
======== Computing dependency graph ========
ERROR: option 'dontexist' doesn't exist
Possible options are ['shared']

The reason is that even for the same package name is very common that options change. New options are added, some options are removed, etc. So failing everytime that an option doesn't exist for any arbitrary version of a package makes it quite annoying for users.

[ashley-b]

Thanks for you quick response and the great work with Conan.

This make sense for patterns, but I just tried conan install --requires=zlib/1.3.1 -o dontexist/1.3.2:dontexist=3 which succeeds

It feels a bit strange that this installs, when package dontexist/1.3.2 does not exist either in the local cache or remotes

[memsharded]

It feels a bit strange that this installs, when package dontexist/1.3.2 does not exist either in the local cache or remotes

Consider that you have it in a profile file instead of command line (recommended to use profile files):

...
[options]
itexists/1.3.2:option=value

Profiles are used thorougly accross projects, so the same profile is applied always for example when creating packages with conan create . -pr=myprofile. But itexists package won't be always in the dependency graph, depending on what package in the graph you are building at that moment. Erroring in that case would be extremely inconvenient, requiring different profiles for different packages in the graph and remembering which one to use.

[ashley-b]

Profiles are used thorougly accross projects, so the same profile is applied always for example when creating packages with conan create . -pr=myprofile. But itexists package won't be always in the dependency graph, depending on what package in the graph you are building at that moment. Erroring in that case would be extremely inconvenient, requiring different profiles for different packages in the graph and remembering which one to use.

Thanks for the detailed use-case, I agree in this instance erroring out would be annoying. But perhaps issuing a warning or info level message about unused options could be useful for debugging.

Thanks again

[memsharded]

Thanks for the detailed use-case, I agree in this instance erroring out would be annoying. But perhaps issuing a warning or info level message about unused options could be useful for debugging.

I am afraid that this would also be too noisy in the output. Consider there are packages out there with tenths of options, like Qt, Boost and others. So users have profiles with a ton of options. Using these profiles for any package other than those ones with so many options, also result in a ton of annoying warnings that also are not real or can be actionable, users also consider them as false positives and report against them.