Just to follow up on this - general support for passing options to memcached clients has landed on master [1], so it's now possible to enable binary mode, pass SASL credentials and also control any other settings using OPTIONS.
For examples, see the end of the cache arguments documentation: https://docs.djangoproject.com/en/dev/topics/cache/#cache-arguments I'm going to try and backport these changes (plus ticket #27152 <https://code.djangoproject.com/ticket/27152>) to django-pylibmc, so the same Django settings file will work for both, to make transitioning from "older Django+django-pylibmc backend" to "Django 1.11+ with stock backend" easier. My ideal end-state is for django-pylibmc to eventually become redundant for the majority of users, with all but the too-specific (eg compression) features being merged into the native backend. Best wishes, Ed [1] https://github.com/django/django/pull/7160 On Monday, 22 February 2016 12:00:31 UTC, Ed Morley wrote: > > Hi Tim, > > Thank you for your reply. > > Yeah I spotted that discussion (it's [6] in the OP). Back then Heroku (and > other PaaS providers) were less common (and I'm not sure how many of those > users frequent this list). > > Given that django-pylibmc has 8000 downloads a month on PyPI (and this is > bearing in mind that Heroku re-uses the virtualenv, so Heroku deployments > won't be counted in that figure aside from updates) I think there is a case > for including it in the default backend - given it would only be a 5-10 > line addition. Even for people who won't be using auth, the new binary mode > is faster, so could be useful regardless. > > I'm happy to put together a PR to make the impact/complexity easier to > judge, if that helps? > > Before I do that I would just need to know whether the `username`, > `password` and `binary` fields should be added to the top level > `CACHES['foo']` dict, or nested inside `OPTIONS` within that? Examples: > https://emorley.pastebin.mozilla.org/8858134 > > Many thanks, > > Ed > > On Monday, 1 February 2016 18:47:17 UTC, Tim Graham wrote: >> >> I found an old discussion about it, but it didn't attract much interest >> at the time: >> https://groups.google.com/d/topic/django-developers/pISp20wuu0E/discussion >> >> On Saturday, January 30, 2016 at 7:21:49 PM UTC-5, Ed Morley wrote: >>> >>> Hi >>> >>> For apps running on Heroku, two of the main memcached options are >>> MemCachier and Memcached Cloud [1]. Both of these control access via SASL >>> authentication, which isn't supported by Django's current pylibmc backend >>> [2], even though pylibmc supports it [3]. As such, currently the >>> django-pylibmc backend has to be used instead [4]. >>> >>> I'd like to add SASL auth support to the Django pylibmc backend to make >>> this unnecessary, which is just a case of passing the relevant parameters >>> through to the pylibmc client during its instantiation [5]. A previous >>> newsgroup discussion about this is at [6]. >>> >>> SASL auth requires binary mode, so I'll also need to add support for >>> that - for which there is already a Django ticket filed [7]. >>> >>> I have a couple of questions: >>> a) Will a PR to add SASL authentication support be accepted? >>> b) If yes to (a), should the `username`, `password` and `binary` fields >>> be added to the top level `CACHES['foo']` dict, or nested inside `OPTIONS` >>> within that? I'm presuming within OPTIONS? Examples: [8]. >>> >>> Many thanks, >>> >>> Ed >>> >>> [1] https://elements.heroku.com/addons#caching >>> [2] >>> https://github.com/django/django/blob/1.9.1/django/core/cache/backends/memcached.py#L181 >>> [3] >>> https://github.com/lericson/pylibmc/blob/1.5.0/src/pylibmc/client.py#L125 >>> [4] https://github.com/django-pylibmc/django-pylibmc >>> [5] eg: >>> https://github.com/django-pylibmc/django-pylibmc/blob/v0.6.1/django_pylibmc/memcached.py#L85-L91 >>> [6] >>> https://groups.google.com/forum/#!searchin/django-developers/pylibmc/django-developers/pISp20wuu0E/tamJ1h8zCzsJ >>> [7] https://code.djangoproject.com/ticket/15815 >>> [8] https://emorley.pastebin.mozilla.org/8858134 >>> >> -- You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-developers+unsubscr...@googlegroups.com. To post to this group, send email to django-developers@googlegroups.com. Visit this group at https://groups.google.com/group/django-developers. To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/634c4d19-8efc-4ef9-a7da-5c3cf3bdd68d%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
