Re: [Configobj-develop] question about config files inclusions

[Michael F. <fuz...@vo...>]

On 22/06/2010 23:20, Etienne Robillard wrote:
> Hi Michael,
>
> Thanks for your input!
>
> I like the idea of defaults settings too.

configspecs are the standard way to provide defaults.

> This makes packages that needs
> configuration files to override only the desired settings. However, as you
> pointed out, my use case is hairy and my development.ini needs some
> refactoring as its having a tendency to accumulate too many sections.
> Shorter config files would be best. Thus, a include statement would include
> all config items and merge them in a Section instance. I will look for
> doing
> a patch as this seems a easy fix..
>    

If you provide a patch I promise to consider it for the next major release.

Michael

>
> Michael Foord wrote:
>    
>> On 21/06/2010 11:35, Etienne Robillard wrote:
>>      
>>> Hi,
>>>
>>> would there be any way to include config files from within
>>> a config section ?
>>>
>>> I would like doing the following:
>>>
>>> [item1]
>>> include path/to/item1.ini
>>>
>>>
>>>        
>> Configobj doesn't currently include any way to "include" sub config
>> files - although it does have programmatic support for merging them
>> (see the merge method).
>>
>>      
>>> Although this seems to break the current RFC-822 rule
>>>
>>>        
>> Configobj isn't bound by rfc-822 anyway. :-)
>>
>>      
>>> for config files section as this statement is missing the equal
>>> syntax control block. However, this would be a great way
>>> to make ConfigObj even more powerful; allowing config items to recycle
>>> common config items. Would there be a better way to include shared
>>> config items with ConfigObj ?
>>>
>>>        
>> Hmmm... I prefer defaults, which obviously doesn't meet all use cases.
>> I'm not sure about this - there are lots of (over the years) different
>> feature requests for cross-referencing, including files, a heirarchy
>> of config files and so on. No single proposal strikes me as
>> particularly elegant nor meets *all* the use cases.
>>
>> I'm open to patches (with tests and documentation of course), but this
>> isn't an itch I particularly feel like scratching myself.
>>      
> No problem, I'll handle and report here once i find some time to investigate
> configobj! ;)
>    
>> All the best,
>>
>> Michael Foord
>>
>>      
> Cheers,
>
> E
>
>    


-- 
http://www.ironpythoninaction.com/
http://www.voidspace.org.uk/blog

READ CAREFULLY. By accepting and reading this email you agree, on behalf of your employer, to release me from all obligations and waivers arising from any and all NON-NEGOTIATED agreements, licenses, terms-of-service, shrinkwrap, clickwrap, browsewrap, confidentiality, non-disclosure, non-compete and acceptable use policies (”BOGUS AGREEMENTS”) that I have entered into with your employer, its partners, licensors, agents and assigns, in perpetuity, without prejudice to my ongoing rights and privileges. You further represent that you have the authority to release me from any BOGUS AGREEMENTS on behalf of your employer.