django-nginx-memcache
django-nginx-memcache copied to clipboard
Fix to get_version() that was preventing setup.py working
Hi there - if you'd like to pull this, feel free. Thanks v much for creating this project - it's something I was going to have to do, too, so it seems to make sense to build on what you've already started and pass as much as I can back upstream!
Cheers Steve
Hey thanks for the interest, I appreciate it.
I copied this approach from the django source mistakenly assuming it'll work, maybe I missed something. I'll update and fix it in a couple of days, but I think the idea is to have some central place to store the version, not to just get it if it's already installed. So maybe the fix is to hard code it in both places instead, or find some way to put it in a 3rd place and import it to both.
I'll have to do some research, or you can try to fix it :)
Hi Paul
My pull request fixes the bug, if you want to use it.
Thanks for creating the project - am using it a a great proof-of-concept for a fork which does a little more (eg alternative cacheing calls other than a decorator; building a cache key from the real/full URI and not just request.path, so that it works on shared servers/servers delivering content for multiple domains). You're welcome to merge anything you want back into your original fork, of course.
By the way, regarding CSRF and form handling - are you sure it works as you expect? We found that nginx was handing back POSTs as 405s, but when I added a 405 handler that punted to @cache_miss via a try_files then it worked fine. Will push to my master branch later so you can see, if you like. To try to replicate, try logging in to the Django admin and see what you get.
Cheers! Steve
Cool. Yes, I want to get these landed. The CSRF stuff works as I expect, you can see it at sowink.com on the landing page, the login form uses it.
Maybe I omitted something from the nginx config. I should probably check.
Yeah, may be worth a check - we certainly had issues with the Django Admin getting 405ed. Our fork is working nicely with that now.
I'm adding a fair bit more to it (currently: a lookup of cached pages, so you can invalidate a whole site or sub-section of pages, if more than one page is affected by a data change). Ideally, I'd call this a 0.2 when it's all done and tested, but it's tricky when it's not the canonical project :o)
You're welcome to have anything back, but I can't tell whether what I'm doing is of interest/use to you, or if it'll feel like I'm going off-piste compared to your original vision.
Hi Paul
My pull request was for a couple of commits made a couple of days ago, not the ones I've made since.
I didn't realise that github's pull requests just take the HEAD commit of a branch on a fork - I'd assumed you could pull in just the little fixes I did to start with. My plan was then to tidy up my fork more and submit another pull request.
Maybe in the meantime you could just look at the diffs for my first two commits, or hang on a few days till I'm done :o)
S