New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Required Conan version #7183
Required Conan version #7183
Conversation
The general configuration `required_conan_version` validates the current Conan client version to the required version. If the current version is out of the range, a warning message is displayed before executing any command. Signed-off-by: Uilian Ries <uilianries@gmail.com>
@property | ||
def required_conan_version(self): | ||
try: | ||
return self.get_item("general.required_conan_version") |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I didn't add support env var, and I don't think that's a good idea. For instance, the company wants a specific version, but the developer overrides that version by env vars
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I want to stop the spread of env-vars as a config mechanism along the conan codebase, because it leads to bad practices, like setting env-vars in recipes, in profiles, that affect how Conan behaves as an application.
The whole purpose of this feature is that developers cannot use a Conan version that they company configuration don't want them to use. Still possible to conan config set general.required_conan_version
.
I am ok with using env-vars that are loaded at app startup time, popped from the environment, and used to initialize the Conan config
object. But that is another feature (that will be breaking for other variables), in the meantime I don't want pull requests to keep adding these env-vars.
out.warn("The current Conan version ({}) does not match to the required version ({})." | ||
.format(client_version, required_version)) | ||
elif result != client_version: | ||
out.warn(result) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
it should not happen ... however, we get the max_satisfying output with no treatment, which means, any change in semver library could generate a false-positive here, like an info message, that's why I preferred to check the obtained version x client_version
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Just make this the condition to raise Error.
self.client = TestClient() | ||
|
||
def test_wrong_version(self): | ||
# include_prerelease is required due the suffix -dev |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The develop branch used -dev by default on its version. Thus, include_prerelease is required. Another option is mocking the client version and using a stable format.
conans/client/conf/__init__.py
Outdated
@@ -261,6 +262,7 @@ class ConanClientConfigParser(ConfigParser, object): | |||
("CONAN_MSBUILD_VERBOSITY", "msbuild_verbosity", None), | |||
("CONAN_CACERT_PATH", "cacert_path", None), | |||
("CONAN_DEFAULT_PACKAGE_ID_MODE", "default_package_id_mode", None), | |||
("CONAN_REQUIRED_CONAN_VERSION", "required_conan_version", None), |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Use only conan.conf, not env-var
output = "" | ||
result = satisfying([client_version], required_version, output) | ||
if not result: | ||
out.warn("The current Conan version ({}) does not match to the required version ({})." |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Implement first a raise exception, and we will see if a warn makes sense in the future. Always introduce features with more restrictive behavior, it can be relaxed later, but the opposite is more difficult.
class RequiredVersionTest(unittest.TestCase): | ||
|
||
def setUp(self): | ||
self.client = TestClient() |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
No need for a setUp() for 1 line only, unnecessary verbosity and indirection
out.warn("The current Conan version ({}) does not match to the required version ({})." | ||
.format(client_version, required_version)) | ||
elif result != client_version: | ||
out.warn(result) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Just make this the condition to raise Error.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Two comments before reviewing:
- I see no reason to support prerelease versions. I would expect a valid semver (not loose). I'm sure we can add some patch to run the tests.
- IMO, this functionality doesn't belong to the command layer, but to the API one, if we connect a different command-line implementation to the
conan_api
, this validation should run. I think we should move this check closer to some init, not sure ifConanAPI
orConanApp
wdyt?
Ok
Yes, agree. I wanted to do a refactor that moved to the api this functionality and the |
Ok, we can use #7170 to check that it is behaving the same with the current CLI and the new one. |
Signed-off-by: Uilian Ries <uilianries@gmail.com>
Done! I've moved to ConanAPI. |
Signed-off-by: Uilian Ries <uilianries@gmail.com>
@property | ||
def required_conan_version(self): | ||
try: | ||
return self.get_item("general.required_conan_version") |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I want to stop the spread of env-vars as a config mechanism along the conan codebase, because it leads to bad practices, like setting env-vars in recipes, in profiles, that affect how Conan behaves as an application.
The whole purpose of this feature is that developers cannot use a Conan version that they company configuration don't want them to use. Still possible to conan config set general.required_conan_version
.
I am ok with using env-vars that are loaded at app startup time, popped from the environment, and used to initialize the Conan config
object. But that is another feature (that will be breaking for other variables), in the meantime I don't want pull requests to keep adding these env-vars.
@memsharded I agree. If the company wants a specific version, the developer shouldn't be able to change. For instance, Windows Policies works like that, but is based on server configuration, and user permission. We would need conan config install with encrypted values or read-only access, otherwise, anyone would be able to change conan.conf |
Signed-off-by: Uilian Ries <uilianries@gmail.com>
@jgsogo I've moved to semver methods, indeed is better now, because is decoupled and requires few lines to parse/validate. |
The general configuration
required_conan_version
validates the current Conan client version to the required version.If the current version is out of the range, a warning message
is displayed before executing any command.
Changelog: Feature: Configuration for checking the required Conan client version.
Docs: conan-io/docs#1740
closes #7136
/cc @memsharded
develop
branch, documenting this one.Note: By default this PR will skip the slower tests and will use a limited set of python versions. Check here how to increase the testing level by writing some tags in the current PR body text.