couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jan Lehnardt <>
Subject Re: Proposal: let -c *not* ignore default.ini
Date Fri, 27 Feb 2009 18:59:00 GMT

On 27 Feb 2009, at 19:48, eric casteleijn wrote:

> Noah Slater wrote:
>> On Fri, Feb 27, 2009 at 02:17:38PM +0100, eric casteleijn wrote:
>>> The only potential problem I see is if the current way .ini files  
>>> are
>>> handled does not allow you to *un*specify a particular option, in  
>>> which
>>> case you'd need to have an option to ignore the default.ini.
>> We cannot accept this patch as is, because it provides no way to  
>> avoid the
>> default configuration file. As it currently stands, if you wish to  
>> use some
>> custom configuration file, it assumed that you know enough about  
>> what you're
>> doing to add in the default or local configuration files as well.
>> To accept your patch, we would need an additional option, like you  
>> mention:
>>  --ignore-default-configuration
>> For me, this weird behaviour breaks the rule of least surprise.
> I understand that, but for me it was actually the reverse. I  
> expected the default.ini to be used unless I specified an option to  
> not use it, and anything I passed into -c to customize the settings  
> I wanted to override. Perhaps it is my zc.buildout history, where  
> you only ever state what needs to be changed, and can even do things  
> like:
> multivalued_option+=value
> multivalued_option-=value
> which makes for an extremely flexible configuration system.
>> Even with the modification suggested, I doubt I would want to  
>> accept this patch.
>> I suggest that you use the following on your local system:
>>  couchdb -c default.ini -c custom.ini
> That is possible, but somewhat undesirable in our setup, since I'm  
> starting several couch servers, and the default.ini and the custom  
> ones will be in different paths, which I would have to compute and  
> pass into that script. Again, not impossible, but I would prefer an  
> option not to do that.
> I can see that a consensus may not be within reach here, so perhaps  
> another option that does provide this behavior could be added, and  
> if we can find clear enough descriptions to distinguish the two.  
> Perhaps override vs. custom(ize) although all the obvious letters  
> have already been taken...

how about

-c file.ini current behaviour
-C file.ini proposed behaviour


View raw message