Configuration (Was: Re: [Trac-dev] Bloodhound / Trac Approach)

[Gary <ga...@wandisco.com>]

On 10/01/12 19:11, Olemis Lang wrote:
> On Tue, Jan 10, 2012 at 2:08 PM, Olemis Lang<ol...@gmail.com>  wrote:
>> On Tue, Jan 10, 2012 at 11:06 AM, Olemis Lang<ol...@gmail.com>  wrote:
>> [...]
>>> maybe a few fields like creation time , owner , project logo (i.e. project fields used in trac.ini ;) should also be considered for inclusion in there . I like the idea of being able to consider projects just like if they were yet another Trac environment inside an environment . That way e.g. external environment may be merged within another and become a project located at a given level of project hierarchy . All that metadata should be kept and reused in new project living (<= oh ! I really wanted to say that ... life is beautiful :) inside target environment . Another goal might be to have all this implemented causing the least impact over existing plugins , preferably no side-effects .
>>>
>>> This makes me wonder whether it would be appropriate to have :
>>>
>>> - project_config table : basically a mirror of trac.ini inside
>>>    database (fields TBD ;)
>> ... or maybe separate project config files in trac.ini ?
> sorry my mistake . I wanted to say :
>
> ... or maybe separate project config files similar to trac.ini in conf folder ?

I think split configuration files might well make sense at some point 
but I probably wouldn't go with that straight away. For now, assuming 
that we are going to make use of the trac.ini file, I would argue that 
we have a reasonable example of how to describe different projects in 
the form of the repositories section. Does a "short_name.property = 
value" form make sense to others?

If we do go with splitting configs at some point, would it be complete 
madness to have some mechanism to include other files so that 
administrators can split their configuration files as they wish?

Cheers,
     Gary