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

Optional user-definable adapter for DEFAULT_FLAG #407

Open
lmeyerov opened this issue Sep 1, 2021 · 1 comment
Open

Optional user-definable adapter for DEFAULT_FLAG #407

lmeyerov opened this issue Sep 1, 2021 · 1 comment

Comments

@lmeyerov
Copy link

lmeyerov commented Sep 1, 2021

Currently, DEFAULT_FLAG is a global default for new flags during WAFFLE_CREATE_MISSING_FLAGS, but that breaks down as soon as 2 flags should have different defaults, or any other late/contextual programmatic determination

One solution is somehow tying this to SETTINGs, as in #50

A more general and Django-y approach would be allowing the specification of a user-defined handler like an Adapter. Ex:

DEFAULT_FLAG_ADAPTER='my.waffle.my_flag_adapter'
...
class my_flag_adapter(waffle_core_flag_adapter):
    def resolve_flag_default(flag: str) -> bool:
      try:
          return config[f'FLAG_{flag};]
      except:
          1
      if flag == 'special_flag_1':
         return True
      return config['DEFAULT_FLAG']

A more static and closed approach would be constance-style precomputed settings:

WAFFLE_FLAG_DEFAULTS = OrderedDict([
  ('flag_x', (env.bool('FLAG_X', default=False))),
  ...
])
@mscansian
Copy link

@lmeyerov The way that it can be mitigated right now is to invert the condition of the flag so that the desired default is always False. Instead of IS_SOMETHING_ACTIVE, flip it to IS_SOMETHING_INACTIVE. But this is annoying. Having an option to set different defaults would be nice.

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

No branches or pull requests

2 participants