Conan: Options with value 'False' are not encoded in package_id

Created on 27 Feb 2020  路  4Comments  路  Source: conan-io/conan

And the issue with the options equal to False is in this line: https://github.com/conan-io/conan/blob/bd5920a40d9707001b31966adb0dfa7d6af00eea/conans/model/options.py#L159

it should be if value is not None, so the False value would be taken into account. This is something we cannot change in Conan v1.x because it will break all existing package IDs, but something to consider for Conan v2.x. I'll open an issue (if there isn't one already).

_Originally posted by @jgsogo in https://github.com/conan-io/conan/issues/6593#issuecomment-592068496_

low high queue look into

Most helpful comment

_Originally posted by @DoDoENT in https://github.com/conan-io/conan/issues/6593#issuecomment-592092783_

OK, I understand the part with deleting the property: the non-existing property is treated the same as a boolean property set to False. If I recall correctly, @memsharded somewhere mentioned that this is actually a feature: it helps in cases when you have a package with no options and then you introduce a boolean option, where False means the behaviour as it was before introducing the option. Hence, the same package ID must be calculated in order to avoid rebuilding packages downstream if no breaking change occurred. This then mandates using self.info_build.options.something = "Any", as you expect. Maybe this is something that would be good to have in documentation as a note.

Of course, another option would be to treat False and None differently.

Yes, that could be a reason, something to take also into account, but you can always introduce that option with the value None.

All 4 comments

Related to https://github.com/conan-io/conan/issues/3740 (no further info) and https://github.com/conan-io/conan/issues/5634 (if we force options values to be strings this is not a problem)

Settings have a different implementation: https://github.com/conan-io/conan/blob/bd5920a40d9707001b31966adb0dfa7d6af00eea/conans/model/values.py#L114

_Originally posted by @DoDoENT in https://github.com/conan-io/conan/issues/6593#issuecomment-592092783_

OK, I understand the part with deleting the property: the non-existing property is treated the same as a boolean property set to False. If I recall correctly, @memsharded somewhere mentioned that this is actually a feature: it helps in cases when you have a package with no options and then you introduce a boolean option, where False means the behaviour as it was before introducing the option. Hence, the same package ID must be calculated in order to avoid rebuilding packages downstream if no breaking change occurred. This then mandates using self.info_build.options.something = "Any", as you expect. Maybe this is something that would be good to have in documentation as a note.

Of course, another option would be to treat False and None differently.

Yes, that could be a reason, something to take also into account, but you can always introduce that option with the value None.

I wasn't even aware that False have such a use case. I have used None for it always, like here:
https://github.com/bincrafters/conan-qt/blob/testing/5.14.1/conanfile.py#L672

Are there examples of packages that do rely on False being a backwards-compatible hash value?

Are there examples of packages that do rely on False being a backwards-compatible hash value?

I think some very early packages in conan-center relied on that. I doubt that any modern package still does (or that it should).

Is there a way to automatically check that?

However, for v2.0 (breaking change), I think it's a no-brainer that None and False should be treated differently.

Was this page helpful?
0 / 5 - 0 ratings