Add 'CONAN_V2_MODE' to start testing Conan v2 deprecated features

[jgsogo]

Changelog: Feature: Add environment variable 'CONAN_V2_MODE' to enable Conan v2 behavior.
Docs: conan-io/docs#1578

If the environment variable CONAN_V2_MODE is defined, Conan will work as Conan v2 (still to provide a roadmap/deprecation summary in a public webpage).

This PR takes care of this breaking changes:

• default settings.yml:
  • first level settings cppstd is removed
• default conan.conf:
  • by default revisions_enabled=1 (we need to write it into the file until [feature] 'conan config get' should return the default value even if it is not initialized #6537)
  • no hooks are activated by default
• scm_to_conandata activated by default
• GCC >= 5 autodetected libcxx is libstdc++11
• Forbid access to self.cpp_info in conanfile::package_id()
• Deprecate conanfile::config()
• Deprecate old python_requires syntax (error raises if it is used, not only if it is imported)
• Forbid access to self.info in conanfile::package()
• default_options required to be a dictionary type
• Raise if scopes in profile
• Raise if setting cppstd in recipe
• Forbid self.settings and self.options in conanfile::source() method
• Deprecate tools.msvc_build_command
• Deprecate tools.build_sln_command
• Deprecate cpp_info.cppflags
• Deprecate environment variables CONAN_USERNAME and CONAN_CHANNEL

It adds several tests to check that the previous errors are actually being raised.

The idea is to inherit these tests from ConanV2ModeTestCase class which is setting the proper variable in the environment. Also, tools like TestClient will be created by this class (for these tests) to ensure that the defaults for v2 are being set.

#REVISIONS: 1

[jgsogo]

@memsharded, wdyt about this approach?

[memsharded]

Looking good, keep going!

[jgsogo]

I think this is enough for the first iteration.

Docs are pending: probably we need a dedicated section in the docs to explain the roadmap to v2 and this environment variable, deprecated features, new defaults,... agree?

[SSE4]

LGTM. the only thing is maybe the name conan_v2_behavior is not that descriptive and too generic. maybe something like check_v2_compatibility would be the better naming?

[jgsogo]

LGTM. the only thing is maybe the name conan_v2_behavior is not that descriptive and too generic. maybe something like check_v2_compatibility would be the better naming?

I'll keep the conan_v2 as it is almost a keyword to search the codebase, but I agree that the behavior part can be improved. Let's wait for @memsharded review before adding more changes.

[memsharded]

Looking good, great job. A couple of things:

• The test_proper_usage tests reads as highly redundant
• Always skipped tests, better to keep them for later
• The conan_v2_property should be no-op without CONAN_V2_MODE env-var, I see that you want to print warnings for v1, but it has a risk that it is not worth it.

[jgsogo]

A comment about the two last points:

• revisions_enabled: last time we agree that Conan v2 (compatibility mode) could keep working without revisions. We can add more things to this CONAN_V2_MODE in the future, in next 1.x releases and there will be plenty of time to remove support for "revisions disabled" (maybe remove the old APIv1). For this PR I think it is enough.
• conan_v2_property I understand the risk, but I'd really like to keep it, it will print the warning, otherwise only people that activate the CONAN_V2_MODE will realize about this wrong usage of Conan. The magic is only applied around very specific class methods, all our tests are green,... it could be as risky as the implementation of the base class for the python_requires.

[memsharded]

revisions_enabled: last time we agree that Conan v2 (compatibility mode) could keep working without revisions. We can add more things to this CONAN_V2_MODE in the future, in next 1.x releases and there will be plenty of time to remove support for "revisions disabled" (maybe remove the old APIv1). For this PR I think it is enough.

Ok, agree.

conan_v2_property I understand the risk, but I'd really like to keep it, it will print the warning, otherwise only people that activate the CONAN_V2_MODE will realize about this wrong usage of Conan. The magic is only applied around very specific class methods, all our tests are green,... it could be as risky as the implementation of the base class for the python_requires.

The thing is that users will certainly not read those warnings, and they will not take action to remove those warnings. It is a nice to have, but I think the real effect on awareness will be very little.

The risk here is users doing unusual things with python, like adding class members inside methods, or weird things over the attribute itself. I really think there is a non small risk of breaking, and given that we are starting to plan for Conan 2.0, these nice to have, informational warnings are not worth.

[jgsogo]

Waiting for the CI, but I'll start with the docs