allow nullifying settings from profiles and command line

[memsharded]

Changelog: Feature: Allow nullifying settings from profiles and command line.
Docs: conan-io/docs#4285

Close #18968
Related to #19031

We have agreed to use the already existing negation syntax ~ as value.

At the moment we will not implement the same for options, as options are already per-package, we didn't find a case for it, so we will better wait for users requests for it.

[kambala-decapitator]

what if a setting needs a literal - value? :) E.g. for w/e reason you want to use it as "stdin"

[memsharded]

what if a setting needs a literal - value? :) E.g. for w/e reason you want to use it as "stdin"

Well, then that would be as NO = Norway....
Settings should be string-meaningful strings, like literal stdin, using that special character is reserved for conan now 🤷 :)

[puetzk]

At the moment we will not implement the same for options, as options are already per-package, we didn't find a case for it, so we will better wait for users requests for it.

I don't have a case where it was truly necessary, but I was looking for this the other day (before deciding conan2 had no way to do this anymore, and doing some re-design).

The scenario was tri-state options = { "test_foo": [None, True, False] } in a test_package . These options guard tool_requires or test_requires that otherwise create circular dependencies, like testing the interaction of a library of build-scripts that help CMake call custom tools, when those custom tools use (other parts of) that same package of build-scripts.

In this pattern, options.test_foo=True means to add a tool_requires and do find_program(... REQUIRED) and definitely test that integration. False means to skip that integration test even if the tool seems to be available (so that you can reliably break the chicken-and-egg problem if you need to deterministically boostrap, without accidentally depending on uncontrolled binaries from the environment). And None (the default) is to just be opportunistic - don't declare the (circular) dependency to conan, but do call find_program (without REQUIRED), and if the tool seems to be available in the buildenv go ahead and do the test. That way a --build missing can initially skip tests and succeed, but eventually do the testing once we've climbed the dependency graph up to the tool itself and started getting things into the buildenv via tested_reference_str. Passing this True/False/None trichotomy from conan to CMake leads to the pattern of if self.options.test_foo != None: tc.variables["TEST_FOO"] = self.options.test_foo in which I stumbled across #19167

Often, then, foo's own test_packages would have default_options = { "cmake-modules/*:test_foo=True }, so that the caller/callee interaction also gets re-tested whenever you change either the tool, or the CMake build-script packages (and in that case, we don't want to skip it the thing we just built seem to be missing from buildenv, we want to fail because something has gone wrong with the package_info).

When I first set things up like this, I observed that you could set test_foo in several different ways, with the hierarchy command-line > profile > default_options, and that conan1 put different values in self.options.test_fo for omitted entirely, vs defaulted and then explicitly overridden back to None. So my Jenkinsfile did have tests with the explicit --options test_foo=None just to cover that scenario, since it was observably different (you got "None" as str instead of as NoneType). Tests of tests of tests, because things you that burned you once become scar tissue :-P.

In porting that test_package and CI pipeline to conan2, I couldn't find any way to pass an explicit --options test_foo=None anymore. But... I was only testing it because it actually produced different input, and digging into #9840 / #19167 had convinced me there was no longer a distinguishable None vs "None" to scenario cover, so I just dropped those cases.

But, short story long, that's place in which I was recently looking for the equivalent of doing --options pkg/*:test_foo=~, couldn't find any such thing, and was at least surprised by the omission. I didn't file an issue because I decided I didn't actually need it, but "overriding default_options from the profile/CLI" is a case where it would at least be a meaningful thing to do, even though options are already per-package