4 ms·

The global settings file is the single biggest hurdle, not only in django deployment, but also development. And it's been like this since I can first remember w

by rlander 15y ago

The global settings file is the single biggest hurdle, not only in django deployment, but also development. And it's been like this since I can first remember with no visible progress. It sucks to keep track of dev/prod local files, it makes it hard to setup a simple script inside of a django environment, it makes multi tenant apps unnecessarily complex, app developers usually want to shove every single configuration option inside of it... If anyone with more than a few hours of django development is doing split settings or something more complex, and even the official docs and best practices recommend doing so, why are we still stuck with it? There are much saner ways to deal with configuration: Flask's[1] is one nice way, as is Padrino's[2]. As a Django dev, this is one of those things that actually makes me jealous of Rails, where the core devs are not afraid of breaking backwards compatibility for sanity's sake. In my opinion it should be priority #1 for an overhaul. [1] http://flask.pocoo.org/docs/config/ http://flask.pocoo.org/docs/config/ [2] http://www.padrinorb.com/guides/mounting-applications http://www.padrinorb.com/guides/mounting-applications

roam 15y ago
I... don't understand your problem. Is it a PITA to split settings files every single time you start a new project? Yes, sure. Does it take more than five minutes to do so? No. Really, Flask's config options are better, but they aren't that different from Django. Use the default settings, tell Django which settings to use from the commandline or specify an environment variable pointing at the settings to use. Where you put those settings is completely up to you - nobody's saying they absolutely positively must be part of your repo. When you're working with multiple environments you'll have to specify which configuration to use one way or another so I'd prefer it to use the least amount of abstraction.
- rlander 15y ago
  If you, me and anyone who's spent more than a few hours with Django split settings.py into multiple files (and heavily modify it), why is it still shipped as one monolithic file? Isn't the framework supposed to make our lives easier? Splitting settings into multiple files is the least of my problems (nowadays it is not a problem at all). The biggest problem I have with it is that it is global, which means I cannot safely modify it at runtime.
  - jpk 15y ago
    Why would you want to modify settings at runtime? Not that I'm saying there's no good reason to, I just don't know.
zalew 15y ago
> As a Django dev, this is one of those things that actually makes me jealous of Rails, where the core devs are not afraid of breaking backwards compatibility for sanity's sake. I work on Django since about 0.9-1.0 and I remember some settings (recently cache, static media) breaking compatibility, so it's not the case. IIRC a new settings module may be introduced in 1.5 and OP's workflow can be automated with fabric.
- rlander 15y ago
  Well, I use Django since 0.95. Still, how long has it been since 0.9-1.0? 8 years? Yes, I already use fabric for deployments.
kmfrk 15y ago
I think there are perfectly fine ways of dealing with it in Django, but it sucks that the documentation does not recognize how vital managing your config is and doesn't expand on the matter. Using a local(_)settings.py feels more esoteric than basic, because you have to find your own blog posts explaining how to do it. Having to come up with your own SECRET_KEY generator for your FOSS Django project feels hacky in a bad way. I don't know if Django has an implementation problem, but I'd say it has a documentation problem.

by rlander 15y ago

roam 15y ago

I... don't understand your problem. Is it a PITA to split settings files every single time you start a new project? Yes, sure. Does it take more than five minutes to do so? No. Really, Flask's config options are better, but they aren't that different from Django. Use the default settings, tell Django which settings to use from the commandline or specify an environment variable pointing at the settings to use. Where you put those settings is completely up to you - nobody's saying they absolutely positively must be part of your repo. When you're working with multiple environments you'll have to specify which configuration to use one way or another so I'd prefer it to use the least amount of abstraction.

rlander 15y ago
If you, me and anyone who's spent more than a few hours with Django split settings.py into multiple files (and heavily modify it), why is it still shipped as one monolithic file? Isn't the framework supposed to make our lives easier? Splitting settings into multiple files is the least of my problems (nowadays it is not a problem at all). The biggest problem I have with it is that it is global, which means I cannot safely modify it at runtime.
- jpk 15y ago
  Why would you want to modify settings at runtime? Not that I'm saying there's no good reason to, I just don't know.

zalew 15y ago

> As a Django dev, this is one of those things that actually makes me jealous of Rails, where the core devs are not afraid of breaking backwards compatibility for sanity's sake. I work on Django since about 0.9-1.0 and I remember some settings (recently cache, static media) breaking compatibility, so it's not the case. IIRC a new settings module may be introduced in 1.5 and OP's workflow can be automated with fabric.

rlander 15y ago
Well, I use Django since 0.95. Still, how long has it been since 0.9-1.0? 8 years? Yes, I already use fabric for deployments.

kmfrk 15y ago

I think there are perfectly fine ways of dealing with it in Django, but it sucks that the documentation does not recognize how vital managing your config is and doesn't expand on the matter. Using a local(_)settings.py feels more esoteric than basic, because you have to find your own blog posts explaining how to do it. Having to come up with your own SECRET_KEY generator for your FOSS Django project feels hacky in a bad way. I don't know if Django has an implementation problem, but I'd say it has a documentation problem.