On 11/2/07, Ned Batchelder <[EMAIL PROTECTED]> wrote: > Sometimes, when a topic comes up over and over, it means something is > wrong. Maybe not the original decision; it could be the documentation, or > the perception of the user base, or whatever. I understand the need to not > revisit old decision ad nauseum, but Carl has an interesting point: whoever > put that "don't share it" comment in the original settings.py file put in on > a single setting, not the entire file. This hints at a distinction in the > author's mind. Maybe our understanding of settings has moved on since then, > or maybe we need to honor that distinction in some way.
I guess I don't share the same interpretation of that comment. Settings files, as far as I'm concerned, are not things to be shared publicly under any circumstances. Note that I've qualified that with the word "publicly", because that's what seems to be the hangup. A team of developers *privately* keeping a settings file in a *private* repository is no problem whatsoever (in fact, that's how we roll here at World Online). But distributing that to the public at large is another matter entirely, and frankly I'm still getting over the idea that anybody would want to do that. Personally I wonder if this is due to a conception that the *project* is somehow the deliverable; I can understand how that conception would be easy to form from the documentation, and I've suggested more than once that the docs should emphasize applications, mentioning projects only as per-installation wrappers for a set of apps being used together. If that's what's happening here, it just adds more fuel to my campaign against emphasizing projects :) > And some settings are important for the functioning of the application (for > example, the list of middleware). Changes made there have to be propagated > somehow to all deployments. In the real world, a single non-shared settings > file simply doesn't work well. I can't help feeling that this is what documentation is for: if your app needs specific settings or combinations of settings, document it. Feel free even to have code somewhere in an __init__.py which checks the settings and raises ImproperlyConfigured if things aren't right. But, from where I stand -- as someone who works both professionally and personally with Django, both individually and as a member of a larger dev team at work -- distributing verbatim settings modules is not the way to do this, and problems encountered by people who do so are in the realm of "if it hurts when you do that, then stop doing that". -- "Bureaucrat Conrad, you are technically correct -- the best kind of correct." --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-users?hl=en -~----------~----~----~----~------~----~------~--~---
