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 <paul.wh...@gmail.com> 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 <joshcar...@gmail.com> 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 <paul.wh...@gmail.com>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 mezzanine-users+unsubscr...@googlegroups.com. >>> >>> 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 >> mezzanine-users+unsubscr...@googlegroups.com. >> >> 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 mezzanine-users+unsubscr...@googlegroups.com. > 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 mezzanine-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
