I think this is how it should go when settings are loaded:
1. goes through all installed apps, and tried to load settings.py.
2. then it loads the django defaults. This way, if an app settings
file tries to override DATABASES or something, it will get reverted to
the django defaults
3. then it loa
Hello...
Modular or divided is not so good as You can feel it now, I think...
For example second web framework I use is symfony. And I hate it
because of this as You say "modularity".
While developing big project I have more then 50 open buffers in emacs
only, plus gvim buffers, plus console window
For the record, the "from settings_default..." method is exactly how
my team's largest projects are deployed. It works just fine for us!
Even more fun (though bordering on too tricky) is converting
INSTALLED_APPS to a set instead of a list so you can add *or* subtract
items.
This whole argument h
On Mon, Jun 7, 2010 at 5:38 PM, Chris wrote:
> On Jun 7, 10:45 am, Alex Gaynor wrote:
>> On Mon, Jun 7, 2010 at 1:15 AM, Chris wrote:
>> >> try:
>> >> from settings_local import *
>> >> except:
>> >> # It's ok to not have any local settings.
>> >> pass
>>
>> > This pattern is used by almos
On Jun 7, 10:45 am, Alex Gaynor wrote:
> On Mon, Jun 7, 2010 at 1:15 AM, Chris wrote:
> >> try:
> >> from settings_local import *
> >> except:
> >> # It's ok to not have any local settings.
> >> pass
>
> > This pattern is used by almost everybody it seems. Is there any reason
> > why this p
On Mon, Jun 7, 2010 at 1:15 AM, Chris wrote:
>> try:
>> from settings_local import *
>> except:
>> # It's ok to not have any local settings.
>> pass
>
> This pattern is used by almost everybody it seems. Is there any reason
> why this pattern hasn't been adopted by "django-admin.py startproj
On Mon, Jun 7, 2010 at 12:28 PM, burc...@gmail.com wrote:
> You have special person for configuring a project.
I wish; just different hats for different tasks.
> You will still be happy.
Only because this sort of auto configuration will not be going into
django, that much has been made abundant
On Mon, Jun 7, 2010 at 4:39 PM, Tom Evans wrote:
> Are you proposing to determine the host name and then dynamically
> import settings from that named configuration file? What a kludge -
> that would require having every configuration file for all your sites
> checked out in the same place.
I'm no
On Sat, Jun 5, 2010 at 11:22 AM, burc...@gmail.com wrote:
> These are exactly my hate patterns.
> The goal of django-configurator was to get rid of them in the projects I have.
So? Problem solved, you can run your projects in precisely the manner
you choose, using your app.
Why then do you
> try:
> from settings_local import *
> except:
> # It's ok to not have any local settings.
> pass
This pattern is used by almost everybody it seems. Is there any reason
why this pattern hasn't been adopted by "django-admin.py startproject"
yet?
--
You received this message because you are
On Jun 5, 11:22 am, "burc...@gmail.com" wrote:
> > It is hardly a stretch to see how this kind of code could be extended
> > to try to import settings_auto or settings_default from each app in
> > installed apps.
>
> Sorry, I'm not native speaker. Can't understand what's "hardly a
> stretch" neit
On Sat, Jun 5, 2010 at 5:07 PM, Tom Evans wrote:
Hi Tom,
> I'm not going to reply again, Russell has quite clearly ruled this out
> but to reply to these points:
>
> As the project manager, you can already use automatic configuration -
> its python, you can do whatever the heck you like. Your scop
On Sat, Jun 5, 2010 at 9:58 AM, burc...@gmail.com wrote:
> On Sat, Jun 5, 2010 at 2:08 PM, Russell Keith-Magee
> wrote:
>> On Sat, Jun 5, 2010 at 2:53 PM, burc...@gmail.com wrote:
>>> On Sat, Jun 5, 2010 at 9:43 AM, Russell Keith-Magee
>>> wrote:
On Fri, Jun 4, 2010 at 11:54 PM, burc...@gm
On Sat, Jun 5, 2010 at 3:53 PM, Vinay Sajip wrote:
>
> On Jun 5, 8:08 am, Russell Keith-Magee
> wrote:
>> in which a user will be using your app. Every single time in my life I
>> have made the statement "Nobody will ever want/need to..." I have been
>> proven wrong. Consider it a corollary of Ru
On Sat, Jun 5, 2010 at 2:08 PM, Russell Keith-Magee
wrote:
> On Sat, Jun 5, 2010 at 2:53 PM, burc...@gmail.com wrote:
>> On Sat, Jun 5, 2010 at 9:43 AM, Russell Keith-Magee
>> wrote:
>>> On Fri, Jun 4, 2010 at 11:54 PM, burc...@gmail.com
>>> wrote:
Hi Russell,
I strongly disagre
On Jun 5, 8:08 am, Russell Keith-Magee
wrote:
> in which a user will be using your app. Every single time in my life I
> have made the statement "Nobody will ever want/need to..." I have been
> proven wrong. Consider it a corollary of Rule 34 :-)
>
That's why the YAGNI principle needs to be appl
On Sat, Jun 5, 2010 at 2:53 PM, burc...@gmail.com wrote:
> On Sat, Jun 5, 2010 at 9:43 AM, Russell Keith-Magee
> wrote:
>> On Fri, Jun 4, 2010 at 11:54 PM, burc...@gmail.com wrote:
>>> Hi Russell,
>>>
>>> I strongly disagree with your and Adrian vision of whether conventions
>>> are good or not.
On Sat, Jun 5, 2010 at 9:43 AM, Russell Keith-Magee
wrote:
> On Fri, Jun 4, 2010 at 11:54 PM, burc...@gmail.com wrote:
>> Hi Russell,
>>
>> I strongly disagree with your and Adrian vision of whether conventions
>> are good or not.
>> But I won't comment that any further. There are your political
On Fri, Jun 4, 2010 at 11:54 PM, burc...@gmail.com wrote:
> Hi Russell,
>
> I strongly disagree with your and Adrian vision of whether conventions
> are good or not.
> But I won't comment that any further. There are your political
> decisions, and I have no single bit of control on them.
> I know
On Fri, Jun 4, 2010 at 4:54 PM, burc...@gmail.com wrote:
> Hi Russell,
>
> I strongly disagree with your and Adrian vision of whether conventions
> are good or not.
> But I won't comment that any further. There are your political
> decisions, and I have no single bit of control on them.
> I know t
Hi Russell,
I strongly disagree with your and Adrian vision of whether conventions
are good or not.
But I won't comment that any further. There are your political
decisions, and I have no single bit of control on them.
I know that it's impossible to persuade you, so why should I spend my
time doin
On Fri, Jun 4, 2010 at 3:30 PM, burc...@gmail.com wrote:
> Hi Russell,
>
> My writing style sometimes is really clumsy. I'm sorry about that.
>
> You might look at the end of the first message in the thread.
> Or maybe the thread topic.
>
> The problem is that half of third party plugins write: "a
I think it is best that each application has its own configuration files.
The problem is usually the opposite, how to use a pluggable application
without changing the source code. And that is why usually the application
writes the global settings.
I'm using this snippet of code in order to separa
Hi Russell,
My writing style sometimes is really clumsy. I'm sorry about that.
You might look at the end of the first message in the thread.
Or maybe the thread topic.
The problem is that half of third party plugins write: "after install,
add this and this and this to settings.py".
The problem i
On Thu, Jun 3, 2010 at 11:19 PM, burc...@gmail.com wrote:
> Hi all,
>
> I've written a prototype, and put it on
> http://github.com/buriy/django-configurator.
> It has few good design decisions, and few maybe not that good.
> Anyway, I consider it as a good addition to app loading GSoC Proposal,
>
Hi all,
I've written a prototype, and put it on
http://github.com/buriy/django-configurator.
It has few good design decisions, and few maybe not that good.
Anyway, I consider it as a good addition to app loading GSoC Proposal,
which is currently being worked on.
The key highlights of the implemen
Hi everybody,
Everyone loves the way templates are discovered in django.
No one loves settings.py that much.
This is proposal on how to improve situation significantly.
Configuration facility is suggested in addition to django.conf.settings.
Configuration is going to be put into conf/ directory
> That's cool -- mind posting your code somewhere?
http://cheeseshop.python.org/pypi/urlrelay/
CheeseShop and setuptools makes installation of even my trivial modules
on my webhost and other places I need it convienient.
>> 1) Develop a loosely coupled module that acts like the "usual" Python
>
On Aug 25, 2006, at 4:34 PM, lugal wrote:
> For a personal project, I modified Django's urlresolvers module to
> make
> it into a piece of WSGI middleware. I liked Django-style URL
> dispatching but I didn't need the whole framework.
That's cool -- mind posting your code somewhere?
> 1) Develo
For a personal project, I modified Django's urlresolvers module to make
it into a piece of WSGI middleware. I liked Django-style URL
dispatching but I didn't need the whole framework.
>From that experience, I can see at least a few ways to modularize
Django components:
1) Develop a loosely coupl
30 matches
Mail list logo
