passing CACHE_OPTIONS when using memcached backends fails

[dwlocks]

If one uses CACHE_ARGS or CACHE_OPTIONS to try to configure a memcached backend client, you get a traceback like this:

  File "/usr/lib64/python2.7/site-packages/flask_caching/__init__.py", line 193, in init_app
    self._set_cache(app, config)
  File "/usr/lib64/python2.7/site-packages/flask_caching/__init__.py", line 219, in _set_cache
    cache_options)
  File "/usr/lib64/python2.7/site-packages/flask_caching/backends/backends.py", line 81, in memcached
    return MemcachedCache(*args, **kwargs)
TypeError: __init__() got an unexpected keyword argument 'behaviors'

I was trying to pass the "behaviors" argument mentioned in the pylibmc docs (http://sendapatch.se/projects/pylibmc/).

It seems that flask-caching faithfully adds the options I've specified. So that's good. The library is doing what it should. The problem is that the underlying werkzeug cache library does not accept any extra arguments or keyword arguments. see around line 488 in https://github.com/pallets/werkzeug/blob/master/werkzeug/contrib/cache.py

From my quick perusal, the backends from cache.py are not consistent in the signature of init. That's probably reasonable given how different the backends are. Only redis accepts **kwargs, and then passes it on to the underlying client. None accept **args.

At the very minimum, CACHE_OPTIONS shouldn't be processed and passed for memcached backends. It would be much better if werkzeug upstream actually accepted **kwargs and passed them on for memcached, though.

workaround
For pylibmc, I think I can:

cache = flask_caching.Cache("localhost")
cache.cache._client.behaviors = {"tcp_nodelay" : True}

[dwlocks]

I also had weird issues if I tried to set the host to "localhost:11211". Yes that's the default port, but this is the development environment. When I deploy, I'll need to be able to configure the port. The bare pylibmc library can parse this correctly. something is getting messed up in the translation, though.

[dwlocks]

Disregard the previous comment: I had a naming conflict with a docker built-in environment variable I was reading for configuration. The only problem is the original one where CONFIG_OPTIONS are not accepted.

[sh4nks]

Sorry for my late reply. Did your workaround work?
I think we should add a note for this in the docs. Would you like to create the PR?

[dwlocks]

Sorry, vacation. The workaround is functional. I'll work on a PR this week.

Would you chime in if I open an issue in werkzeug?

[dwlocks]

pr #48 adds a note.

[sh4nks]

Would you chime in if I open an issue in werkzeug?

Yeah, sure.

Thanks for your PR, just merged it!