Maybe I was the one who didn't quite understand ;) Apologies if I jumped the gun with my comments.
On Wed, May 28, 2014 at 4:24 PM, Paul Whipp <[email protected]> wrote: > Thanks for the feedback Josh, I enjoy Django and am enjoying my increasing > familiarity with Mezzanine. After rebuilding my own > website<http://paulwhippconsulting.com>with it, I've now created and deployed > four client sites on Mezzanine so > far. > > INSTALLED_APPS is not in scope in local_settings.py so that line will not > work and importing the settings in order to bring INSTALLED_APPS into scope > is non-trivial because of the circularity issues. > > For sensitive data I prefer to use environment variables so that the (non > security relevant) settings for the various site installations are not left > out of the repo requiring manual updates on each site when they change. > > Putting the secure settings in local_settings.py results in developers and > testers copying the file every which way - not good for security. While the > same can be said of the bash script that sets up the secure elements as > environment variables, this file quite literally stays unchanged for the > life of the project so there is far less need to copy it about. > > With the applications I have, a single development location and a single > live site are not a common scenario (when they are the case, I leave > local_settings.py as it is... until it becomes a pain). It has to go when > there are staging sites, test sites, local variations for testers, mappers, > developers... > > My workaround is effective and I recommend it for any Mezzanine site where > you need to deal with more than two working installations. > > Don't mistake this for my not liking Mezzanine; it provides excellent > leverage by giving me a lot of useful functionality from the outset without > getting in the way of adding complex apps for data presentation. > > > On 29 May 2014 00:21, Josh Cartmell <[email protected]> wrote: > >> 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 a topic in the >> Google Groups "Mezzanine Users" group. >> To unsubscribe from this topic, visit >> https://groups.google.com/d/topic/mezzanine-users/NIyPsTXK5po/unsubscribe >> . >> To unsubscribe from this group and all its topics, 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. > -- 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.
