Re: Setting dictionaries (was Re: integrating django-secure)

On 09/05/2014 03:11 PM, Marc Tamlyn wrote: > Yup, that works. The issue is that most users never explicitly call > django.setup(), so they need to know how to modify manage.py and wsgi.py > to do > > conf = MyProjectConfig() > django.setup(conf) > > > In the case of wsgi.py this isn't too

Re: Setting dictionaries (was Re: integrating django-secure)

Yup, that works. The issue is that most users never explicitly call django.setup(), so they need to know how to modify manage.py and wsgi.py to do conf = MyProjectConfig() django.setup(conf) In the case of wsgi.py this isn't too obtuse, but django.setup() is here -

Re: Setting dictionaries (was Re: integrating django-secure)

On 09/05/2014 02:54 PM, Marc Tamlyn wrote: > I like the idea Russ - from a brief peruse of the code base it's > apparently to me how disparate the handling of various "setup" settings > is throughout the codebase. For example: > > INSTALLED_APPS is handled by django.setup() and Apps.populate()

Re: Setting dictionaries (was Re: integrating django-secure)

I like the idea Russ - from a brief peruse of the code base it's apparently to me how disparate the handling of various "setup" settings is throughout the codebase. For example: INSTALLED_APPS is handled by django.setup() and Apps.populate() (cached attribute) MIDDLEWARE_CLASSES is handled by

Re: @load_fixture annotation for test cases.

On Tuesday 02 September 2014 15:27:53 Josh Smeaton wrote: > > As far as I'm concerned, using fixtures is the wrong way to populate data > for tests. You're much better off creating the objects you need for each > test within the test, or creating them directly inside the setUp method. +1. > You

Re: Setting dictionaries (was Re: integrating django-secure)

Hi Ryan, On 09/05/2014 12:02 PM, Ryan Hiebert wrote: > ​I'd like to see the email settings get moved into a dictionary so that > I can use a single environment variable to configure it very easily, ala > dj-database-url. There's dj-email-url right now, but it requires 7 lines > to configure

Re: Setting dictionaries (was Re: integrating django-secure)

Hi Russ, On 09/05/2014 10:38 AM, Russell Keith-Magee wrote: > The other way to resolve this would be to rethink the way Django starts up. > > Settings like MIDDLEWARE_CLASSES have always struck me as being a little > odd - they're not really settings, they're a way to configure the way > code

Re: The greatest proposal yet: rename this damn group

Russ, I think the suggestion was merely to change the display name of the group. I don't see any downsides to trying something like "Django developers (core development)". On Friday, September 5, 2014 1:45:58 PM UTC-4, Russell Keith-Magee wrote: > > > Hi Robert, > > Thanks for the suggestion.

Re: The greatest proposal yet: rename this damn group

Hi Robert, Thanks for the suggestion. You're not the first to make the suggestion - the same suggestion has been made many times in the past. You can search the archives if you want to see those discussions. There are a number of problems with this proposal: 1) History. There are 10 years of

Re: Django views/templates vs. Javascript MVC Front-ends

I think many people are going the django-as-a-REST-server route. -- You received this message because you are subscribed to the Google Groups "Django developers" group. To unsubscribe from this group and stop receiving emails from it, send an email to

Django views/templates vs. Javascript MVC Front-ends

It seems that the MVC Javascript systems like Angular and Ember are winning the front-end. They're very responsive compared to being served files from the back-end - no need to wait for server responses, since there's a local cache subset of the database in the browser. It would probably be

Re: Proposal: enhance 1.7 migration docs re django.core.handlers.wsgi:WSGIHandler()

Hi Robert, The "old" version breaks because it's now missing a key part of the Django startup sequence: import django django.setup() This is something that was added in 1.7 as part of the app loading changes. So, to answer your questions directly: 1) You either need to use

Re: Proposal: enhance 1.7 migration docs re django.core.handlers.wsgi:WSGIHandler()

I ran into this problem myself upgrading to to django 1.7. The secret is that get_wsgi_application calls django.setup() which is now required to initialize django. I went through and switched all my code to use get_wsgi_application(). get_wsgi_application() has been in the default wsgi.py in

Re: The greatest proposal yet: rename this damn group

Or Django contributors? On Friday, 5 September 2014 10:20:51 UTC+2, Tom Christie wrote: > > Options?... > > * Django core > * Django core development > > For comparison the Rails folks have "Ruby on Rails: Talk > " and "Ruby on > Rails:

Re: The greatest proposal yet: rename this damn group

Options?... * Django core * Django core development For comparison the Rails folks have "Ruby on Rails: Talk " and "Ruby on Rails: Core " - Tom On Friday, 5 September 2014

Proposal: enhance 1.7 migration docs re django.core.handlers.wsgi:WSGIHandler()

I was using import django.core.handlers.wsgi application = django.core.handlers.wsgi.WSGIHandler() as per whichever *This Is The Right Way To Lay Out A Django Application* article I was reading at the time. This seems to now break in 1.7 (details - from someone else - here