This changeset fixes the installed packages. Previously, flask_featureflags.contrib sub packages (including inline and sqlalchemy) were not installed through pip install flask-featureflags.

I want to add the key to my sqlalchemy database if it does not exist in any other handler. I can listen to some flask signal in this case to do that.

Is it a good idea? I can work on it, but maybe others have better ideas about how to handle it.

This is the fix the following warning which happens whenever the module is loaded: ExtDeprecationWarning: Importing flask.ext.featureflags is deprecated, use flask_featureflags instead. from flask.ext.featureflags import NoFeatureFlagFound, log

Was trying to use InlineFeatureFlag (as described here), but found that the contrib modules weren't being included. Small change to setup.py fixes it.

My proposal to make an SQLAlchemy handler.

You just need a SQLAlchemy instance (from Flask-SQLAlchemy extension) and a check method in the model.

from flask import Flask
from flask.ext.sqlalchemy import SQLAlchemy
from flask.ext.featureflags import FeatureFlag
from flask.ext.featureflags.contrib.sqlalchemy import SQLAlchemyFeatureFlags

app = Flask(__name__)
db = SQLAlchemy(app)
handler = SQLAlchemyFeatureFlags(db)

ff = FeatureFlag(app)
ff.add_handlers(handler)

As a fellow lover of python and flask, and having written a feature-switching backend application with an administrative UI, I would like to contribute an integration between the two. Is that something you'd be interested in?

https://github.com/giftig/flippy

I was actually inspired by gargoyle / django-gargoule when writing flippy, which worked very similarly to your lib.

I'm genuinely not sure why I've never written my own python connector to it.

Previously, flask_featureflags.__version__ is set to 0.4dev while setup.py is set to 0.7-dev. This changeset ensures consistent version found in flask_featureflags.__version__ and setup.py.

You can check the version in Python shell:

>>> import flask_featureflags
>>> print(flask_featureflags.__version__)
0.7-dev

and using pip freeze:

$ pip freeze | grep FeatureFlags
Flask-FeatureFlags==0.7.dev0

The changesets introduce custom handler for inline feature flags.

One notable difference is, instead of specifying feature flags in dict-style:

FEATURE_FLAGS = {
    "finished": False,
}

the flag must be written in uppercased plain string with FEATURE_FLAGS_X where X is the feature name:

FEATURE_FLAGS_FINISHED = False

The motivation behind this custom handler is to interopt with other Flask extensions, e.g. Flask-AppConfig.

This tripped me up a bit, so thought explicitly stating the order of decorators could help.

This works (404s):

@app.route('/feature-flag-test-route')
@is_active_feature('test_route')
def feature_flag_test_route():
    return 'on!'

This does not (returns 200, displays 'on!')

@is_active_feature('test_route')
@app.route('/feature-flag-test-route')
def feature_flag_test_route():
    return 'on!'

The handler is not responsible to handle the feature flag missing. I expect the KeyError only if it was not found in any handler.

The current implementation works for only one handler.

This is my first step to create a custom handler. I want to make the core responsible for missing keys.

I'm not sure about the exception name. Django use DoesNotExist, SQLAlchemy use NoResultFound, but I tried FeatureFlagNotFound, NotFound, FeatureNotFound and others.

It's not possible to use url_for() in the decorator call if the app context is not build yet. Therefore this patch adds a new optional argument named redirect to is_active_feature. It's the same as redirect_to but it triggers url_for() right before the redirect.

Flask no longer recommend using the "flask.ext." import style; this change eliminates the warning currently generated by flask when using this extension.

http://flask.pocoo.org/docs/0.12/extensiondev/#extension-import-transition

(The 0.12 docs are somewhat contradictory on this, but the confusing text seems to have been removed in the latest dev docs.)