Hey Paul, it seems like you don't quite understand how local_settings.py
works. A project's settings.py imports local_settings.py allowing you to
override settings as you like. For example, in local_settings.py you could
put:
INSTALLED_APPS += ("debug_toolbar",)
just like you want.
Also, leaving local_settings.py out of version control is intentional since
it often contains sensitive information (db/email/etc... passwords) and
settings that are different between development/production. Mezzanine does
have a version of local_settings.py that is included in version control and
if you are using the fabfile to deploy it gets copied to a production
server to server as it's local_settings.py. That file is your project's
deploy/local_settings.py.template (formerly deploy/live_settings.py). In
that way you can have settings that are particular to your dev environment
in local_settings.py and settings specific to your production environment
in deploy/local_settings.py.template.
On Wed, May 28, 2014 at 12:23 AM, Paul Whipp <[email protected]> wrote:
> Having the local_settings always outside of version control is a pain on
> large projects and not being able to arbitrarily alter settings (rather
> than simply overwrite them) is agony.
>
> In 'normal' Django, the 'two scoops' method can easily be used to replace
> the local_settings.py import but in Mezzanine, there is the dynamic
> settings stuff at the end which both obfuscates how the settings are being
> set up and makes removing the use of local_settings relatively tricky.
>
> For example; say I need to include an app - e.g. "debug_toolbar" so I want
> my local settings to have a line that does:
>
> INSTALLED_APPS += ("debug_toolbar",)
>
>
> In 'plain Django' I'd have a settings/base.py for all the base settings
> and I'd have a settings/dev.py that imports from it:
>
> from settings.base import *
>
> INSTALLED_APPS += ("debug_toolbar",)
>
>
> Then my settings environment variable imports settings.dev locally and
> settings.live on the live site (or settings.staging... as appropriate) (I
> set this DJANGO_SETTINGS_MODULE in my virtualenv postactivate script making
> it a 'fire and forget' solution across multiple servers and sites).
>
> The Mezzanine workaround is to make the 'local_settings' follow on from
> the set_dynamic_settings: Remove its import from the main settings file
> (which moves to settings/base.py) and then use a settings.dev.py as above
> for your 'local' settings (call it 'local' if you like but we have testers
> who run builds locally with different settings so that confuses things for
> us).
>
> Mezzanine would be cleaner and easier to use if it abandoned the use of
> 'set_dynamic_settings' altogether.
>
>
> --
> You received this message because you are subscribed to the Google Groups
> "Mezzanine Users" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to [email protected].
> For more options, visit https://groups.google.com/d/optout.
>
--
You received this message because you are subscribed to the Google Groups
"Mezzanine Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
For more options, visit https://groups.google.com/d/optout.
