fix: Using correct default number as config version. #1305
Merged
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Because of the value of
config.Config.CONFIG_VERSION
the current version of the config files used by the latest stable BIT release is6
.This fix take care that this number is used by default for (empty) config files that don't specify
config.version
by their own.This problem was introduced by a commit in the year 2016.
In the wild with normal users this touch only some edge cases. But it is highly relevant for unittesting where some of tests do use empty config files.
This PR also solves a problem and the need for an associated workaround encountered by @aryoda. The problem here was that in some cases (e.g. when running TravisCI) a message appeared on
stdout
that informed about the automatic conversion of the config file from version 5 to 6. That pollutes the json output of--diagnostics
. I will modify that specific unittest later in the context of my "Config-as-singleton" PR I am preparing.Just another sitenote: This points to another "problem" when using
--diagnostics
. In that case the log level should be set to "warnings" so that "info" messages can not pollute the json output. But the BIT's ownlogger
module doesn't provide that. We could only use some "hacks" via the low-level modulesyslog
. The wholelogger
module should be replaced in the feature by Pythons ownlogging
module. But I won't touch it yet and it seems not to be so urgent. :)