On 18 nov 2005, at 18.03, Adrian Holovaty wrote:
On 11/18/05, David Ascher <[EMAIL PROTECTED]> wrote:
I guess I wasn't clear. What p4 does (and I propose django-admin
does) is
look for an environment variable called DJANGO_SETTINGS_NAME, and
use "
settings.py" if it doesn't find such an e
hugo wrote:
> lookup might be nice for dev I am not absolutely against it - please
> keep the "override settings location by environment variable" working.
>
> bye, Georg
>
>
Was it ever implied anywhere that DJANGO_SETTINGS_MODULE would stop
working? This is a default - the extra measures that
Sune Kirkeby wrote:
> On 11/18/05, Robert Wittams <[EMAIL PROTECTED]> wrote:
>
>>The current system breaks a holy guideline as well: DRY.
>>You have to specify the settings module even though you have almost
>>certainly mentioned it already - your current working directory.
>
>
> Uhmm.. Not tru
>An idea: It could be a new settings module d.s.like_perforce,
>which finds the settings-file like described, evals it and reexports
>the settings it contains. That way everything will still work
>like normal for the rest of us (no nasty surprises because you
>cd to someplace down-path from a sett
On 11/18/05, Robert Wittams <[EMAIL PROTECTED]> wrote:
> The current system breaks a holy guideline as well: DRY.
> You have to specify the settings module even though you have almost
> certainly mentioned it already - your current working directory.
Uhmm.. Not true at all. I package my apps sepa
Sune Kirkeby wrote:
> On 11/18/05, David Ascher <[EMAIL PROTECTED]> wrote:
>
>>So I don't think it would break under apache -- Apache would still require
>>the same environment variable to be set. But maybe I'm missing something?
>
>
> My point exactly :) Also, if a users places a settings-fil
On 11/18/05, Simon Willison <[EMAIL PROTECTED]> wrote:
>
> On 18 Nov 2005, at 18:26, David Ascher wrote:
>
> > It's very possible that the use case it supports (repeatedly
> > switching b/w projects when invoking django-admin.py) isn't
> > frequent enough to warrant the increased complexity.
>
> I
Regarding the original issue (putting the project directory into the
PYTHONPATH), is the implication that django-admin would automagically
append the directory where it locates the settings.py file to sys.path?
Or is this not intended to address that concern at all?
BTW Simon, beware; "knock up"
On 18 Nov 2005, at 19:37, Simon Willison wrote:
On 18 Nov 2005, at 18:26, David Ascher wrote:
It's very possible that the use case it supports (repeatedly
switching b/w projects when invoking django-admin.py) isn't
frequent enough to warrant the increased complexity.
It's frequent enough t
On 18 Nov 2005, at 18:26, David Ascher wrote:
It's very possible that the use case it supports (repeatedly
switching b/w projects when invoking django-admin.py) isn't
frequent enough to warrant the increased complexity.
It's frequent enough to drive me potty. I think I'll try to knock up
On 11/18/05, Sune Kirkeby <[EMAIL PROTECTED]> wrote:
I guess all this just rubs me the wrong way, because it breaksthe Only One Way guideline.And it should thus be challenged, no argument here.It's very possible that the use case it supports (repeatedly switching b/w projects when invoking
django-
On 11/18/05, David Ascher <[EMAIL PROTECTED]> wrote:
> So I don't think it would break under apache -- Apache would still require
> the same environment variable to be set. But maybe I'm missing something?
My point exactly :) Also, if a users places a settings-file outside her
PYTHON_PATH, it wi
On 11/18/05, Adrian Holovaty <[EMAIL PROTECTED]> wrote:
> Oooh, this is a nice idea! Is anybody willing to submit a patch?
An idea: It could be a new settings module d.s.like_perforce,
which finds the settings-file like described, evals it and reexports
the settings it contains. That way everythi
On 11/18/05, Sune Kirkeby <[EMAIL PROTECTED]> wrote:
I suggest this, because I think it's a rather poor idea; my biggestproblem with it is that it will break under Apache. So suddenlydjango-admin and the handlers do different things, which isbound to cause surprises...
That's exactly the kind of f
On 11/18/05, David Ascher <[EMAIL PROTECTED]> wrote:
> I guess I wasn't clear. What p4 does (and I propose django-admin does) is
> look for an environment variable called DJANGO_SETTINGS_NAME, and use "
> settings.py" if it doesn't find such an environment variable. It then looks
> for a file wi
On 18 Nov 2005, at 15:49, Robert Wittams wrote:
I think that sounds pretty good.
+1 - sounds excellent to me.
David Ascher wrote:
> On 11/17/05, Tim Keating <[EMAIL PROTECTED]> wrote:
>
>>
>>It's an interesting idea . . . I know why perforce works this way, but
>>I'm curious what problem this addresses. Most of the stuff that lives
>>in the P4CONFIG file is located in /settings.py, as far as I
>>can tell
On 11/17/05, Tim Keating <[EMAIL PROTECTED]> wrote:
It's an interesting idea . . . I know why perforce works this way, butI'm curious what problem this addresses. Most of the stuff that livesin the P4CONFIG file is located in /settings.py, as far as I
can tell. And I'm not clear how this would solv
It's an interesting idea . . . I know why perforce works this way, but
I'm curious what problem this addresses. Most of the stuff that lives
in the P4CONFIG file is located in /settings.py, as far as I
can tell. And I'm not clear how this would solve the problem of Python
knowing where to look for
I'm just starting w/ Django, so I may be a bit off, but the way I'd
have liked to see the setting of DJANGO_SETTINGS done is like what
Perforce does with its configuration files. Specifically, a
combination of environment variables (with a Registry-persisted version
on Windows, although that's le
I have recently discovered the joy of .pth files. I respectfully submit
that having django-admin create one of these for you as part of running
startproject would be a cleaner (and more cross-platform) solution than
what you propose here.
Implementation details aside, +1 for the idea!
The most confusing part of the Django tutorial right now is the
futzing around with paths:
"""
Now, take a second to make sure myproject is on your Python path. You
can do this by copying myproject to Python's site-packages directory,
or you can do it by altering the PYTHONPATH environmen
22 matches
Mail list logo
