Features dictionary in qbzr
Alexander Belchenko
I've just committed to qbzr trunk one experimental function:
I've added FEATURES dictionary to allow the external code based on qbzr
itself be able to check whether some new feature present in the
installed copy of qbzr or not. I have a hope it makes our integration
between qbzr and bzr-explorer (or maybe with bzr-colo as well) more tighter.
Excerpt from the code:
# Features dictionary:
# keys are feature names, values are optional parameters for those features.
# the meaning of parameters depend on the feature, so it's more like config.
# The keys names can use namespaces in the form 'domain.option'.
#
# Intended usage of this dict by the external code:
#
# if feature_name in FEATURES: then_do_something(); else:
backward_compatible_code()
#
# or
#
# feature_value = FEATURES.get(feature_name); if feature_value == XXX:
the_do_something()
#
# NOTE: No external code should add the keys or change the values to
this dict!!!
#
FEATURES = dict(
# feature_name=None, # for features without extra parameters
# feature_name='1.2.3', # to specify optional version or parameter
# feature_name=[some list], # to specify the list of parameters
# etc.
)
Right now this dict is very free-form as you can see, and I don't plan
to put everything we have there right now. If some external code will
have a need to see some feature added to that dictionary then please
create a merge proposal with short explanation what you need.
Let's dogfood it for some time and see is it become useful thing or not.
So maybe other parts of bzr ecosystem will want use the similar approach
too.
Alexander
--
All the dude wanted was his rug back