If this is about making deployment easier, then it might take long
before anybody contributes windows support.
After inheriting from the projects settings "from myproject.settings
import *", I have not experienced the caveats.
Something as simple as overriding a settings file as never been
easier
I implemented this based upon the code snippet I showed in my first reply.
Anyone who wishes to use DJANGO_SETTINGS_FILE can now pip install
django-settings-file and follow its setup instructions:
https://pypi.python.org/pypi/django-settings-file
I've added some caveats I thought of d
On 09/04/17 16:16, Josh Smeaton wrote:
So I think there are a few questions to go over.
1. What are the more successful strategies that work in the wild?
(files in /etc/, PYTHONPATH, env vars, local_settings.py)
2. Are any of the above clearly superior?
3. Is this a serious problem that peo
Thanks friends, of course Daniele for the backup, and also James for
the advice of course now that my first emotional reaction is over -
thanks for your tolerance.
Thanks for reading pretty much everything I have on this subject,
looking forward to read feedback from all django-dev contributors of
FWIW - I wasn't completely sure what the problem was you were relating or
the solution you were proposing as a means to fix it. I came to this thread
a bit late, and was probably overwhelmed by lots of text without reading
and understand your first message in the thread well enough. The big
rep
On Sat, Apr 8, 2017, James Pic wrote:
>I'm sorry you've seized the opportunity to use my effort to put a little
>joy and humor in my message to push me on the slope, sorry that it's been
>misinterpreted and that I just don't understand at all your technical
>explanation. I guess there is always t
tl;dr
I'm not debating deployment here: my automated deployments are fine
the way it is today: I love linux and env vars, shells and subshells
and so on.
I'm /reporting/ that users have been fighting the lack for
DJANGO_SETTINGS_FILE for as long as I can remember.
In many case, they
uires writing an undocumented JSON
configuration file or something as warry as that. Currently I have to learn
each and every environment-specific settings file app there is out there
just in case somebody adds it to their project because of the lack of
DJANGO_SETTINGS_FILE.
After all, isn't the f
I'm sorry you've seized the opportunity to use my effort to put a little
joy and humor in my message to push me on the slope, sorry that it's been
misinterpreted and that I just don't understand at all your technical
explanation. I guess there is always that risk.
Best
James
Le 7 avr. 2017 10:43 P
On Thu, Apr 6, 2017 at 5:22 PM, James Pic wrote:
> Do I need this to deploy my projects ? No of course, because I use the
> prettiest way hhihihi ;) I'm more than happy to win a debate
>
Please don't do this. This does not make you look like someone who I could
constructively engage with to try
lone aesthetics,
DJANGO_SETTINGS_MODULE=production_settings
PYTHONPATH=/etc/yourapp:$PYTHONPATH is basically a lot more
error-prone than DJANGO_SETTINGS_FILE=/etc/yourapp/production.py, is
it even necessary to demonstrate this ? This somewhat reminds my
favorite talk this year, "Don't fight the controls&
quot;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_F
hat 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 se
You could do this already by putting a file on PYTHONPATH that just reads
the contents of the file specified by DJANGO_SETTINGS_FILE and puts it in
its own module dict, e.g.
$ cat ~/tmp/test.py
foobar = 12
$ TEST_SETTINGS_FILE=~/tmp/test.py ipython
...
In [1]: import imp, os
In [2]: test
hat 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
15 matches
Mail list logo
