Skip to content
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

Merged

Conversation

uilianries
Copy link
Member

@uilianries uilianries commented Jun 10, 2020

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

  • Refer to the issue that supports this Pull Request.
  • If the issue has missing info, explain the purpose/use case/pain/need that covers this Pull Request.
  • I've read the Contributing guide.
  • I've followed the PEP8 style guides for Python code.
  • I've opened another PR in the Conan docs repo to the 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.

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")
Copy link
Member Author

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

Copy link
Member

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)
Copy link
Member Author

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

Copy link
Member

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
Copy link
Member Author

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.

@@ -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),
Copy link
Member

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 ({})."
Copy link
Member

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()
Copy link
Member

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)
Copy link
Member

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.

Copy link
Contributor

@jgsogo jgsogo left a 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 if ConanAPI or ConanApp

wdyt?

@memsharded
Copy link
Member

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.

Ok

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 if ConanAPI or ConanApp

Yes, agree. I wanted to do a refactor that moved to the api this functionality and the auto_config_install one. I am fine with doing it in a later Pull Request too.

@jgsogo
Copy link
Contributor

jgsogo commented Jun 11, 2020

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>
@uilianries
Copy link
Member Author

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")
Copy link
Member

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.

@uilianries
Copy link
Member Author

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>
@uilianries
Copy link
Member Author

@jgsogo I've moved to semver methods, indeed is better now, because is decoupled and requires few lines to parse/validate.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

[feature] Min (max) conan version checks from conan.conf
3 participants