Re: DJANGO_SETTINGS_FILE

[Chris Church]

Look through https://code.djangoproject.com/wiki/SplitSettings for many
different approaches to loading settings from files that aren't importable
as Python modules.

My personal favorite is django-split-settings, which would let you
accomplish exactly what you're trying to do.


On Thu, Apr 6, 2017 at 9:50 AM, Tobias McNulty 
wrote:

> I don't see Django making a change like this. If it's really impossible to
> get your production settings file on an already-importable Python path, you
> *could* modify your PYTHONPATH
> 
> environment variable to add the directory containing your Django settings
> file. That being said, I think you're better off keeping all your settings
> files in version control where they belong, and changing the things you
> need to change via environment variables.
>
> On Thu, Apr 6, 2017 at 9:20 AM, James Pic  wrote:
>
>> Hi all!
>>
>> Life with DJANGO_SETTINGS_MODULE has been great. However, it requires the
>> settings to be an importable module. In most cases, this is a straight
>> forward "simple" python script.
>>
>> Sometimes it looks like it could make sense to add an environment
>> variable that could use a file that is not importable as a python module,
>> ie.:
>>
>> DJANGO_SETTINGS_FILE=/etc/yourapp/production.py
>> DJANGO_SETTINGS_FILE=~/yourapp_production.py
>> DJANGO_SETTINGS_FILE=settings.py  # relative to pwd
>>
>> Then, in this file, we could override the default project settings there
>> without having to put the new file in an importable module, ie. in
>> /etc/yourapp/production.py:
>>
>> from yourapp.settings import *
>> DATABASES=...
>> CACHES=...
>> SECRET_KEY=...
>>
>> I'm sure this has been discussed before but didn't find anything by
>> searching DJANGO_SETTINGS_FILE in the ML.
>>
>> What's your opinion on this ? Is it time to upgrade this ?
>>
>> Best,
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "Django developers (Contributions to Django itself)" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to django-developers+unsubscr...@googlegroups.com.
>> To post to this group, send email to django-developers@googlegroups.com.
>> Visit this group at https://groups.google.com/group/django-developers.
>> To view this discussion on the web visit https://groups.google.com/d/ms
>> gid/django-developers/CAC6Op19-0JeL8Jdcq70-pvwz%2Bi2hfKtopEv
>> ihca_rGfH1DrPww%40mail.gmail.com
>> 
>> .
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>
>
> --
>
>
> *Tobias McNulty*Chief Executive Officer
>
> tob...@caktusgroup.com
> www.caktusgroup.com
>
> --
> You received this message because you are subscribed to the Google Groups
> "Django developers (Contributions to Django itself)" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to django-developers+unsubscr...@googlegroups.com.
> To post to this group, send email to django-developers@googlegroups.com.
> Visit this group at https://groups.google.com/group/django-developers.
> To view this discussion on the web visit https://groups.google.com/d/
> msgid/django-developers/CAMGFDKThapJkEykuhxFEuTF%2BZNjHNr7t6p%
> 3Dssenb0qM85DVXyQ%40mail.gmail.com
> 
> .
>
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAH%2BKTJ6nisgP7AC99V0S0zkYGPVu_5oKQCF%3DQ39XEz_0%3Dn9B_Q%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: manage.py and pyc's

[Chris Church]

It looks like this issue has been marked as wontfix in
https://code.djangoproject.com/ticket/14952

However, I've used the following in manage.py to support running management
commands when distributing only .pyc files:

https://gist.github.com/cchurch/6067733




On Tue, Jul 23, 2013 at 6:29 PM, Jan Vilhuber  wrote:

> In our project, we typically deploy our django app without py's, except
> for a few select ones (manage,py for example). I recently added a few
> management/commands to a few of the apps in my project, and discovered that
> manage.py does not find them, as it looks only for .py files (ignoring
> .pyc's; django.core.management.__init__::29 in django 1.4).
>
> Any reason why this is so? Could commands be discovered by regular python
> introspection rather than looking for py files?
>
> jan
>
>  --
> You received this message because you are subscribed to the Google Groups
> "Django developers" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to django-developers+unsubscr...@googlegroups.com.
> To post to this group, send email to django-developers@googlegroups.com.
> Visit this group at http://groups.google.com/group/django-developers.
> For more options, visit https://groups.google.com/groups/opt_out.
>
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
For more options, visit https://groups.google.com/groups/opt_out.

Re: secret key from file...

[Chris Church]

I've used the execfile approach in my settings.py like so:

# Include any local settings that override the defaults.
try:
execfile('local_settings.py')
# Hack so that the autoreload will detect changes to local_settings.py.
class dummymodule(str):
__file__ = property(lambda self: self)
sys.modules['local_settings'] = dummymodule('local_settings.py')
except IOError:
pass


The advantage of execfile over an import is that the local_settings is
executed within the settings.py namespace, so your local_settings.py can
read or modify default/global settings (add its own middleware, installed
apps, etc).

That all being said, I think it's best left to each project or team or
developer to decide how to make settings.py work for them and hide any
sensitive information.


On Tue, Mar 22, 2011 at 7:09 PM, Matt Robenolt wrote:

> That's just interesting. I've never seen the use of `execfile()` before. We
> use a devsettings.py and use it to override an individual server or local
> settings, and then on the live/deployed server, no devsettings.py is even
> included. Hence the try...except wrapped around it. It's a nice little
> pattern that gets us by, but yes, things like this do show that there needs
> to be one overall "recommended" method for maintaining separate settings on
> a per server/environment basis.
>
> On Mar 22, 2011, at 7:05 PM, Ian Kelly wrote:
>
> > On Tue, Mar 22, 2011 at 4:49 PM, Matt Robenolt
> >  wrote:
> >> Why not just do an import for your custom settings?
> >>
> >> try:
> >>from site_settings import *
> >> except ImportError:
> >>pass
> >
> > No particularly compelling reason that I know of, the import machinery
> > is just unnecessary in this case.  The site_settings.py is viewed as
> > an extension of the settings.py, so it doesn't need to be loaded as a
> > module in its own right.  And for the same reason we know exactly
> > where we expect the file to be, so there's no need to consult
> > sys.path.
> >
> > I suppose it just comes down to a matter of taste.
> >
> > Cheers,
> > Ian
> >
> > --
> > You received this message because you are subscribed to the Google Groups
> "Django developers" group.
> > To post to this group, send email to django-developers@googlegroups.com.
> > To unsubscribe from this group, send email to
> django-developers+unsubscr...@googlegroups.com.
> > For more options, visit this group at
> http://groups.google.com/group/django-developers?hl=en.
> >
>
> --
> You received this message because you are subscribed to the Google Groups
> "Django developers" group.
> To post to this group, send email to django-developers@googlegroups.com.
> To unsubscribe from this group, send email to
> django-developers+unsubscr...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/django-developers?hl=en.
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.