Ok, understood. All I wanted was discussion (or dismissal by simple
matter of reason as your latest reply and my subsequent new
understanding of the dev server's relationship to an application
implies) about my original post. The thread started out with Jacob
basically saying, "there's your solutio
On Sunday, September 26, 2010, Yo-Yo Ma wrote:
> I apologize Russell. There's been a gross understanding of what I was
> asking. I'm not asking how to do "if settings.debug: x = y". I'm
> asking for a way to set settings.debug to true dynamically without
> having to rely on deployment specific iss
I apologize Russell. There's been a gross understanding of what I was
asking. I'm not asking how to do "if settings.debug: x = y". I'm
asking for a way to set settings.debug to true dynamically without
having to rely on deployment specific issues. Ie, pass a variable in
when the dev server is run (
On Sat, Sep 25, 2010 at 8:59 AM, Yo-Yo Ma wrote:
> Chuck - Thanks. Perhaps there isn't such room for improvement on the
> topic.
>
> Jacob - It appears to me that you don't read things before you comment
> on them. That's two times in one post. Patience is a virtue, my
> friend.
This conversation
Chuck - Thanks. Perhaps there isn't such room for improvement on the
topic.
Jacob - It appears to me that you don't read things before you comment
on them. That's two times in one post. Patience is a virtue, my
friend.
On Sep 24, 3:12 pm, Chuck Harmston wrote:
> My technique, which allows you to
My technique, which allows you to:
- Segregate settings per environment
- Keep environmental settings under version control
- Have multiple environments on a single host (using an environment
variable set by the WSGI script)
- Keep passwords and other sensitive information out of so
On Fri, Sep 24, 2010 at 3:50 PM, Yo-Yo Ma wrote:
>
> What if I want dev settings in version control?
>
> What if I want "explicit"?
At this point this discussion is getting pretty far off-topic; can you
please take it to django-users?
Thanks,
Jacob
--
You received this message because you are
On Sat, Sep 25, 2010 at 3:50 AM, Yo-Yo Ma wrote:
>
> What if I want dev settings in version control?
Please write in details.
Do you have single development configuration or multiple? Single
development PC or multiple?
> What if I want "explicit"?
Aren't they explicit enough?
Ok, version 3.
sett
If everything is under version control, you'll need to detect the server
status somehow. Some options:
- check the absolute path of the settings file on the filesystem if you can
ensure this path is different on the production server
- import socket; and check socket.gethostname()
- check for "runs
On Sat, Sep 25, 2010 at 12:46 AM, Chuck Harmston
wrote:
> their project (with the help of a programming language). That is powerful.
...But is not very practical for 90% of django users, who have to
invent their own bikes.
> However, that flexibility isn't solely restricted to the method of defin
What if I want dev settings in version control?
What if I want "explicit"?
On Sep 24, 11:09 am, "burc...@gmail.com" wrote:
> How it's better from both of the following:
>
> 1)
> try:
> from dev_settings import *
> except ImportError:
> pass
>
> 2)
> if DEBUG:
> from dev_settings imp
Forgive the slight tangent, but I think it's important to understand why
settings are defined in Python and not a markup language (like some RoR
settings are). It's a very intentional design decision that gives developers
the flexibility to define settings in a way that makes the most sense for
the
How it's better from both of the following:
1)
try:
from dev_settings import *
except ImportError:
pass
2)
if DEBUG:
from dev_settings import *
Because to have "project.is_dev" you'll have to write it somewhere already!
It's bootstrapping problem.
On Sat, Sep 25, 2010 at 12:01 AM, Y
I read that article. The problem is that it's deployment specific. I
dint even know what host name "omh.cc" is, but I have a feeling that
you couldn't work on that from your laptop to your desktop without
changing something. What I propose isn't a is_production variable. I'm
proposing an explicit i
Thanks for the link David. I'm gonna check it it now.
On Sep 23, 6:16 pm, "David P. Novakovic"
wrote:
> This link and the comments suggest some good stuff... particularly the
> comment from Malcolm and the original post.
>
> http://www.protocolostomy.com/2009/08/17/django-settings-in-dev-and-p...
This link and the comments suggest some good stuff... particularly the
comment from Malcolm and the original post.
http://www.protocolostomy.com/2009/08/17/django-settings-in-dev-and-production-why-the-hoops/
On Fri, Sep 24, 2010 at 10:01 AM, David P. Novakovic
wrote:
> The thing is, in product
The thing is, in production mode you normally have to define where
your settings are anyway, so you pass the unusual settings file name
there, and just use the regular settings.py for your development.
So then you are passing the settings configuration information once in
the production server's c
Did you read my post?
> I don't like having to check for specific things
> like to see if I'm in live or development mode in my settings
I'm talking about having 2 sets of settings, and differentiating them
without having to use stuff like ``import os`` or web server specific
things to discern b
Thanks David, but I'm talking about having something built in. For
instance, passing a variable to the "Development" server to tell it
you're in "Development" seems a bit redundant, no?
On Sep 23, 3:39 pm, "David P. Novakovic"
wrote:
> As for running different configs:
>
> manage.py runserver --s
As for running different configs:
manage.py runserver --settings=settings_test
etc..
On Fri, Sep 24, 2010 at 7:25 AM, Jacob Kaplan-Moss wrote:
> On Thu, Sep 23, 2010 at 3:33 PM, Yo-Yo Ma wrote:
>> I'm simply proposing the idea of having the development server
>> explicitly set something to ind
On Thu, Sep 23, 2010 at 3:33 PM, Yo-Yo Ma wrote:
> I'm simply proposing the idea of having the development server
> explicitly set something to indicate a "in development" status, so
> that if that does not exist you can make the assumption that the
> project is live.
This is exactly what the set
21 matches
Mail list logo
