dbsettings, and user configurable app settings

[Jared Forsyth]

I have been looking around for a way of managing user-configurable
application settings, and the only solution I have found is dbsettings,
which looks like it hasn't been touched in 3 years.
So, I would like to know: is dbsettings dead? Or is there a different
generally accepted method for having user-friendly app settings? (e.g. don't
require code modification)

I think that this idea is pretty essential to django's ease of use; there
are many applications which have (or should have) settings which only effect
UI or minor behavioral issues, and shouldn't require a server restart to
effect (and imo shouldn't require server write access). It seems that the
most viable solution would be to have a database managed settings system (in
the form of a .contrib module) which would manage this. It also seems that
having such an infrastructure in place would really encourage app
maintainers to have more settings, thereby making the apps even more
portable.

Any thoughts?

Thanks,
Jared

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@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.

Re: dbsettings, and user configurable app settings

[Jared Forsyth]

If you look at dbsettings (which again, might be dead - i don't know) it
solves a lot of those problems; settings are tied into the "sites" module,
and are presented to the user in a very friendly way. The problem of db
migration is still there, but I can envision an import/export to XML (or
something) functionality where you can get/transfer all settings (or just
for one/a few apps) to another installation.
I've forked my own copy of dbsettings for the project I'm currently working
on (as I said, it was last touched 2007, and out-of-the-box incompatible),
and improving, so I might try to get it polished and more integrated w/
contrib.admin, and see how it works.

Jared

On Fri, Feb 26, 2010 at 11:00 AM, Wes Winham  wrote:

> I'd love to see a better way of managing settings in the core of
> django. It's a real pain point sometimes for writing and using
> pluggable applications and there's a wide range of ways that
> application developers try to tackle it. Some have basically no
> settings, some plan on users reading the documentation and defining
> all required settings, some have a way of using defaults that can be
> overridden and some have hacked together ways of using the database
> for some settings (I think ReviewBoard does something like this, or
> did). The problem I see is that the *best* way hasn't really bubbled
> to the surface as far as I can tell. Kind of like how database
> migrations are a hard problem, settings management seems kind of
> tricky.
>
> Are there things stopping someone from making a really good app for
> managing settings and letting that bubble up to the de facto solution
> like with South? If there are, maybe removing those things would be a
> good target before trying to build the actual solution in contrib. Of
> course, this is probably not the best time for discussing this since
> everyone is trying to get 1.2 out the door, but I'd love to see this
> area improved down the road.
>
> My specific pain points:
>  * With a given app, it's a crapshoot to find where they define their
> internal settings (some use app/conf/settings.py, some app/conf/
> default.py, some app/default.py etc)
>  * It's hard to tweak settings on deployment for different
> environments. Using a settings_local.py that gets included is a
> workable solution, but it requires you to maintain a monolithic file.
> Something like the conf.d/*.conf debian style of configuration might
>
> Pinax is having a similar discussion right now. Maybe something will
> come out of that project that can be applied/adapted to some later
> version of django. That might be a place to apply some development if
> anyone is interested in working towards better settings management.
>
> http://groups.google.com/group/pinax-core-dev/browse_thread/thread/d9401468ea3c8edf
>
> -Wes
>
> On Feb 26, 2:11 am, Jared Forsyth  wrote:
> > I have been looking around for a way of managing user-configurable
> > application settings, and the only solution I have found is dbsettings,
> > which looks like it hasn't been touched in 3 years.
> > So, I would like to know: is dbsettings dead? Or is there a different
> > generally accepted method for having user-friendly app settings? (e.g.
> don't
> > require code modification)
> >
> > I think that this idea is pretty essential to django's ease of use; there
> > are many applications which have (or should have) settings which only
> effect
> > UI or minor behavioral issues, and shouldn't require a server restart to
> > effect (and imo shouldn't require server write access). It seems that the
> > most viable solution would be to have a database managed settings system
> (in
> > the form of a .contrib module) which would manage this. It also seems
> that
> > having such an infrastructure in place would really encourage app
> > maintainers to have more settings, thereby making the apps even more
> > portable.
> >
> > Any thoughts?
> >
> > Thanks,
> > Jared
>
> --
> You received this message because you are subscribed to the Google Groups
> "Django developers" group.
> To post to this group, send email to django-develop...@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-develop...@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.

Re: dbsettings, and user configurable app settings

[Jared Forsyth]

I'm currently working on a solution to this which I call appsettings, and I
think it addresses many of the concerns raised here. appsettings loads your
module's settings.py in much the same way that contrib.admin loads your
admin.py, and you call appsettings.register (can be used as a decorator) to
tell appsettings that you want those settings managed.
Once registered with appsettings, you access your settings through
appsettings.settings.mymodule.xyz. e.g.

import appsettings
settings = appsettings.settings.mymodule

@ the top of some file.

appsettings uses the database to store your configuration, but it also
gracefully degrades in the absence of a database -- all settings are still
accessible, but are read-only.

Take a look at the project on github for a better example/docs:
http://github.com/jabapyth/django-appsettings

 Jared

On Tue, Mar 2, 2010 at 2:40 PM, Carl Meyer  wrote:

> On Mar 1, 9:40 am, stuff4ash  wrote:
> > I am not necesary advocating magic. But the need for a more robust (or
> > lets say, any) configuration management exists for many.
>
> "Configuration management" is a fuzzy phrase that can mean many things
> to many people. I think it'd be more helpful to focus on specific
> problems and possible solutions. My critique was specifically of the
> suggestion you made for an automatic import of app-level settings.py,
> which introduces magical behavior for (AFAICS) no gain. I've certainly
> had the need for something like dbsettings or livesettings, though
> I've often addressed it with a separate app/model rather than trying
> to shoehorn django.conf.settings into a role it wasn't intended for. I
> also agree that for projects with many reusable apps (which describes
> all of mine), split settings are less headache to manage; I like
> Transifex' conf-directory solution and have proposed it for Pinax.
>
> It's not that the status quo is perfect and no improvement is
> possible; just that specific suggestions with concrete use-cases are
> more useful than handwavy claims about the need for some major new
> subsystem whose purpose and specific features are not clear.
>
> > I am very familiar with your setup, and its the best one in use I have
> > seen. but it has several shortcomings.
>
> So what shortcomings are relevant to you?
>
> > one of the few times that I wished django was more plonish.
>
> Which means what, in this case?
>
> Carl
>
> --
> You received this message because you are subscribed to the Google Groups
> "Django developers" group.
> To post to this group, send email to django-develop...@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-develop...@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.

2 small tickets

[Jared Forsyth]

I found some bugs, wrote come patches, submitted some tickets. =) Is that
all that's needed?
The two patches I wrote are *very* small, one is only one char diff...
I guess I just want to know
a) have I done all that's required/suggested, and
b) if so, what's the expected turnaround time for very small bugs w/ a patch
attached?
for reference, the tickets: http://code.djangoproject.com/ticket/12974,
http://code.djangoproject.com/ticket/12972

thanks,
Jared

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@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.

Re: 2 small tickets

[Jared Forsyth]

As a general "best practices" question: When I update a ticket w/ a test
case and better patch, do I uncheck 'needs better patch' and 'needs
testcases'? Or do I leave that to the person who originally checked them?

thanks,
Jared

On Wed, Mar 3, 2010 at 1:08 AM, Russell Keith-Magee
wrote:

> On Wed, Mar 3, 2010 at 3:41 PM, Jared Forsyth 
> wrote:
> > I found some bugs, wrote come patches, submitted some tickets. =) Is that
> > all that's needed?
> > The two patches I wrote are very small, one is only one char diff...
> > I guess I just want to know
> > a) have I done all that's required/suggested, and
>
> As has been noted elsewhere, the big thing missing from both tickets
> is a test case -- or at least a very compelling reason why a test case
> isn't possible.
>
> > b) if so, what's the expected turnaround time for very small bugs w/ a
> patch
> > attached?
>
> "It depends" :-)
>
> Bugs get fixed when they get fixed. The core team are all volunteers,
> so it's impossible for us to make guarantees about when certain bugs
> will be fixed.
>
> Right now, we're trying to push 1.2 out the door, so bugs that are
> critical to that release are taking priority. This means bugs that
> have been introduced in the 1.2 release (regressions, or bugs with new
> features). If this affects your bugs, they should be marked with the
> 1.2 milestone, which improves the chance they will be committed in the
> near future.
>
> If your ticket doesn't meet these criteria, then all I can advise is
> patience.
>
> Yours
> Russ Magee %-)
>
> --
> You received this message because you are subscribed to the Google Groups
> "Django developers" group.
> To post to this group, send email to django-develop...@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-develop...@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.

Re: dbsettings, and user configurable app settings

[Jared Forsyth]

I think there are some settings which are for the developer, and some which
are appropriate for an admin user, who is not necessarily the developer, to
have access to. In addition, there are some settings which should be
modifiable without necessitating a server restart.
There is value in having configuration options which are available to a user
who doesn't have server write access.

jared

On Wed, Mar 3, 2010 at 8:07 PM, orokusaki  wrote:

> I don't think that settings are for users. They are for the developer.
> The type of settings you are looking for really should be set up as
> part of your application. Users can't choose a DB password or your
> server's time zone, or which apps are installed. If you're creating an
> SAAS you'd be better to have a configuration app that has fields for
> storing account / user specific settings.
>
> --
> You received this message because you are subscribed to the Google Groups
> "Django developers" group.
> To post to this group, send email to django-develop...@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-develop...@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.

Re: 2 small tickets

[Jared Forsyth]

Is there a good tutorial/docs on "adding tests to django"? It took me a
while to figure out/guess the structure/organization of tests, and I'm still
not sure whether I've done it right (for reference here's the
patch<http://code.djangoproject.com/attachment/ticket/12972/flatpages_admin_trunk.diff>I
ended up with).

Thanks
Jared

On Wed, Mar 3, 2010 at 11:24 AM, Karen Tracey  wrote:

> On Wed, Mar 3, 2010 at 12:33 PM, Jared Forsyth wrote:
>
>> As a general "best practices" question: When I update a ticket w/ a test
>> case and better patch, do I uncheck 'needs better patch' and 'needs
>> testcases'? Or do I leave that to the person who originally checked them?
>>
>
> If you believe you have addressed whatever made someone set "needs better
> patch" you should turn that off.  Similarly if you have added what you
> believe are appropriate and sufficient tests, you should turn off "needs
> tests".
>
> Karen
>
> --
> You received this message because you are subscribed to the Google Groups
> "Django developers" group.
> To post to this group, send email to django-develop...@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-develop...@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.

Re: Django documentation for newer users

[Jared Forsyth]

To be honest I am quicker to just go to django's source code rather than the
docs, as often I can find what I need there, and the docs aren't (imo)
organized enough to provide much of an advantage.

On Fri, Mar 5, 2010 at 8:46 AM, stherrien  wrote:

> Hi all,
>
>
> I have a request that django documentation show the import locations
> for classes like in other well formed docs found on the web showing
> the users where the classes can be found for import. I think this
> would be handy for newer users and experienced users finding something
> new. Documentation on the site is different from page to page. Take
> for instance the file object doc page in django doesn't tell the user
> where this can be imported which requires you to dig into the python
> help pages to try and find it. which is "from django.core.files.base
> import File". it would be nice to show this consistently across the
> site. I would be happy to help make this happen.
>
>
> -shawn
>
> --
> You received this message because you are subscribed to the Google Groups
> "Django developers" group.
> To post to this group, send email to django-develop...@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-develop...@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.

Re: Easier debugging of Django templates. {% try %} ... {% endtry %} template tag and traceback.

[Jared Forsyth]

I presume these only get shown with DEBUG turned on?

On Fri, Mar 5, 2010 at 9:09 AM, Jonathan S wrote:

> Hi Django users,
>
> We made at our company, City Live, a template tag you may be
> interested in.
> It's a try/catch statement. When anything in the try block fails, a
> traceback through all the included templates is shown.
>
> A good approach would be to include {% try %} ... {% endtry %} in the
> base template of the whole site, so that any template rendering error
> will be caught.
>
> If you prefer a custom message instead of the traceback, the following
> is also possible:
> {% try %} ... {% except %} custom error message {% endtry %}
>
>
> Screenshot of the traceback, embedded in our site:
>
> http://github.com/citylive/Django-Template-Tags/blob/master/screenshots/traceback.png
>
> Source:
>
> http://github.com/citylive/Django-Template-Tags/blob/master/templatetags/debug.py
>
> It depends on this {% stylize %} template tag and pygments for the
> highlighting.
>
> http://github.com/citylive/Django-Template-Tags/blob/master/templatetags/stylize.py
>
> All feedback is welcome!
>
> Jonathan
>
> --
> You received this message because you are subscribed to the Google Groups
> "Django developers" group.
> To post to this group, send email to django-develop...@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-develop...@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.

Re: Easier debugging of Django templates. {% try %} ... {% endtry %} template tag and traceback.

[Jared Forsyth]

On a related note, is there a way to tell templates *not* to fail silently?
(most tags etc. do)
for testing/debugging purposes?

jared

On Fri, Mar 5, 2010 at 9:53 AM, Jonathan S wrote:

>
> On Mar 5, 5:49 pm, Jared Forsyth  wrote:
> > I presume these only get shown with DEBUG turned on?
>
> Yes, they are only shown when DEBUG is on:
>
> see line 163:
>
> http://github.com/citylive/Django-Template-Tags/blob/master/templatetags/debug.py#L163
>
>
> --
> You received this message because you are subscribed to the Google Groups
> "Django developers" group.
> To post to this group, send email to django-develop...@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-develop...@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.

Re: dbsettings, and user configurable app settings

[Jared Forsyth]

It seems like the best place for "project settings"(a) would be applicable
is through some ./manage.py command, perhaps "installapps" or something
along those lines. This would probably be the place to do database
modifications between versions.
(b) could be served by a "readonly" flag in the settings (if you were using
appsettings)
and (c) is provided by appsettings out of the box.
So it looks like the thing that needs work/thought/design decisions would be
(a). Could you give an example use case of that sort of "project
installation setting"?

Jared

On Sat, Mar 6, 2010 at 5:56 AM, stuff4ash  wrote:

> Sorry Carl, I agree with pretty much everything you said. I was
> talking a bit too abstract and I had misunderstood.
> I will concentrate on a few use cases:
>
> with a app level settings.py file i didnt really refer to automatic
> import, as that can easily be done now.
> I had more like a admin.register in mind, like the appsettings app by
> jared.
> it would be nice if apps had an easy and constitent way of
> "registering" somehow:
>
> a) project settings (settings that affect the installation, etc...
> this can include automatic install of dependencies, etc... but
> normally do not change, this could be done in a similar script )
> b) app settings (settings that change once and while, but that are
> meant to be changed by a superuser, or admin)
> c) user settings (settings that are to be set and changed by a user
> himself, that could be changed in a "profile app")
>
>
> more to come, now is food time
>
> --
> You received this message because you are subscribed to the Google Groups
> "Django developers" group.
> To post to this group, send email to django-develop...@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-develop...@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.

Re: dbsettings, and user configurable app settings

[Jared Forsyth]

As far as a solution that "magically solves everyone's problem nicely",
that's what django-appsettingsis
trying to be :). It handles quite nicely the issues of scoping and
maintainability that you discussed, organizing everything in a pythonic
manner.

Jared

On Wed, Mar 10, 2010 at 7:51 AM, Brian Rosner  wrote:

>
> On Mar 10, 2010, at 7:16 AM, Joan Miller wrote:
>
> > It's a disaster from the maintenance view point. If it were not so,
> > then people would not be proposing to refactor the settings as has
> > been made in Pinax, or from multiple posts so many times.
>
> Like I mentioned in the post you made to the pinax-core-dev mailing list
> the problem Pinax is trying to solve is *not* because the settings are
> written in Python, but rather loading order and scope. Many projects quickly
> realize that running a Django project with a single settings file is nearly
> impossible with different environments all interacting with a single code
> base. Some projects turn to importing a local_settings.py file which is what
> Pinax currently does. This has worked wonderful for us for years. However,
> there has always been a scoping issue. It was difficult to easily change
> settings defined at the "global" level (this being project-wide settings
> that are environment agnostic). You'd have to copy them to the
> local_settings.py and add in extra values or remove existing values. One
> approach to solve this problem is to flip the loading order (imports happen
> at the settings.py level including the project level settings). While this
> works it presents a problem to usability. It would require an extra step on
> behalf of the user to either copy or create a missing settings file to run.
> This was a non-starter in Pinax since a fundamental goal is to get up and go
> once you've created the project. We've ultimately ended up on the solution
> Carl gave which can be read on our mailing list.
>
> I don't see how your YAML configuration solves any of these problems. You'd
> have to create a similar mechanism with where you parse YAML files and then
> you are solving the same problem we are. If there is a solution you have in
> mind that magically solves everyone's problem nicely then present that
> instead of hand waving.
>
> Brian Rosner
> http://oebfare.com
> http://twitter.com/brosner
>
> --
> You received this message because you are subscribed to the Google Groups
> "Django developers" group.
> To post to this group, send email to django-develop...@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-develop...@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.

Re: Proposal - ChoiceField.choices need to accept callable, not only list or tuple

[Jared Forsyth]

I say go for it, and post again with a patch and issue number (once you've
created them). Your idea seems sound.

Jared

On Mon, Mar 22, 2010 at 11:30 PM, George Karpenkov
wrote:

> Hi,
>
> The subject pretty much describes all of it. If 'initial' can be a
> callable, why 'choices' can't? Writing custom function is way more
> convenient then altering __init__ method of the model.
>
> I'm happy to write up a patch if it would be likely to be accepted
>
> --
> You received this message because you are subscribed to the Google Groups
> "Django developers" group.
> To post to this group, send email to django-develop...@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-develop...@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.