User and system config files

[Chris Shoemaker]

On Fri, Jan 20, 2006 at 12:19:15AM -0500, Chris Shoemaker wrote:
> Author: chris
> Date: 2006-01-20 00:19:15 -0500 (Fri, 20 Jan 2006)
> New Revision: 12909
> Trac: http://svn.gnucash.org/trac/changeset/12909
> 
> Modified:
>    gnucash/trunk/src/bin/Makefile.am
>    gnucash/trunk/src/bin/gnucash-bin.c
>    gnucash/trunk/src/scm/command-line.scm
>    gnucash/trunk/src/scm/main.scm
>    gnucash/trunk/src/scm/path.scm
> Log:
>   Move the loading of user and system config files from guile to C.
> 
>   Remove the "load config" command line options, since they weren't doing 
>   anything different than the default. 

Just a heads up:

If you've been seeing something like:
gnucash: [W] "failed to load /home/chris/.gnucash/config-2.0.auto"

on startup for some time now it's probably because your config files
aren't compatible with the current gnucash.  If this is the case, the
C code complains using the normal logging facilities
(/tmp/gnucash.trace) instead of the console.  It also prints the whole
guile backtrace there (if your config file crashes, obviously.)

I had been ignoring that warning for quite a long time now, but after
seeing the backtrace in the logs, it's quite obvious what's causing
them.  gnc:config-file-format-version doesn't exist anymore.  That
raises an interesting point...

These days, I'm especially mindful of forward and backward
compatibility concerns.  I think we need to think carefully about what
expectations our users might have about the compatibility of their
config files.  By allowing the user to supply a guile file to be
loaded at startup, we're giving them enormous flexibility to change
the behavior of gnucash.  But, we're also exposing an _enormous_
public interface -- essentially every guile function and gwrapped
function or datatype -- an interface that I don't think is so ready to
be cast in concrete.

I think we have several options.  The simplest is to simple warn users
that custom guile scripts they write could be broken by even minor
releases.  Another option is to be more rigid about what data we load
from guile config files.  We don't _have_ to execute the user's
program -- we could just pull out certain config values.  I'm sure
there are more options.

What I want to avoid is the sense that we can't change any g-wrapped
function or guile function just because we're potentially executing
user scripts that may use any of those.  It's something to think
about.

-chris