Conan: [suggestion] Search custom sub-settings

[uilianries]

To help us debug your issue please explain:

From slack discussion: https://cpplang.slack.com/archives/C41CWV9HA/p1560980070212900

For now conan search is only able to look regular settings, as os, arch, build_type and compiler, but it's limited in terms of customized settings, for example:

$ conan search openssl/1.0.2s@ennor/stable -q "os=iOS"
Existing packages for recipe openssl/1.0.2s@ennor/stable:
    Package_ID: 08859e5949c46fd78bb8b4d045f854329c141a56
        [settings]
            build_type: Release
            compiler: apple-clang
            compiler.version: 10.0
            os: iOS
            os.version: 10.0
        Outdated from recipe: False
    Package_ID: 5d2c60a906ecd568347527895bc32e4890264eea
        [settings]
            build_type: Debug
            compiler: apple-clang
            compiler.version: 10.0
            os: iOS
            os.version: 10.0
        Outdated from recipe: False

$ conan search openssl/1.0.2s@ennor/stable -q "os.version=10.0"
Existing packages for recipe openssl/1.0.2s@ennor/stable:

There are no packages for reference 'openssl/1.0.2s@ennor/stable' matching the query 'os.version=10.0'

conan search openssl/1.0.2s@ennor/stable -q "os=iOS AND os.version=10.0"
Existing packages for recipe openssl/1.0.2s@ennor/stable:

There are no packages for reference 'openssl/1.0.2s@ennor/stable' matching the query 'os=iOS AND os.version=10.0'

The command search is limited because the rule:

https://github.com/conan-io/conan/blob/df8fd41b63ee3054fe1160ded5e52e19c0a933c3/conans/search/search.py#L85

The suggestion is supporting custom settings, or sub-settings at least.

Regards!

/cc @Minimonium @Paultergeist

• [x] I've read the CONTRIBUTING guide.
• [ ] I've specified the Conan version, operating system version and any tool that can be relevant.
• [x] I've explained the steps to reproduce the error or the motivation/use case of the question/suggestion.

[jgsogo]

It would be a nice addtion. It is already working for compiler.xxxx, so it should be easy to extend it to subsettings at least.

[Minimonium]

@jgsogo the question here is:
Would check for info_settings.get(prop_name, None) being None and only then fall back to options be a breaking change?
The query feature is very convenient and users do expect that it would work with their custom settings.

[jgsogo]

Uff, the border between breaking and not-breaking changes sometimes is too thin... We would break things like:

• custom settings matching the name of an option, now we would be looking for the setting instead of the option
• and option matching a subsetting pattern (os.version), now we would be looking for the subsetting instead of looking for the option
• people with invalid queries that now are finding nothing, and they will start to obtain results

Not sure if any of these use-cases is strong enough to block the feature, wdyt?

[Minimonium]

Custom settings named the same as options
and option matching a subsetting pattern (os.version)

That's a "funny" case indeed. Though we have a problem even now if the user makes an option named the same as the setting from the blessed list, right? Should we have a special syntax for for-sure options? project:name? Not sure.

people with invalid queries that now are finding nothing, and they will start to obtain results

Are these "invalid" queries though? The query syntax doesn't differentiate options and settings, so it's very questionable what's the expected behaviour here. It may as well be a bug from the user perspective.
And again, making a list of blessed settings in that part of the code makes an unfortunate dependency on the implementation of settings and punishes users with custom ones.

[uilianries]

If some user is using a duplicated property name for settings and options, I see it like a prone error.

As @Minimonium said, we could add a prefix or tag to indicate that we are looking for a setting or an options. It can helps when someone uses custom settings, like for embedded stuff.

Another option, following the current implementation, is detecting the properties according the current settings.yml file. It would be more dynamic.

[memsharded]

After reviewing https://github.com/conan-io/conan/pull/5521, I think it is not breaking, it is extending the same sub-settings search that was done in compiler to other subsettings, it makes sense, and having options named as settings seems that was already broken for search.

I think we want to allow queries over root level custom settings too, and be absolutely deterministic about what is resolving, settings, or options. For that purpose, we might need to use the syntax:

$ conan search ... -q="option:my_option=some_value ... "

And assume otherwise it will be a setting. I will create a new issue for this.