Hi, the core of my proposal is to NOT normally edit config/*
config/*.ini should be UNCOMMENTED .ini files which are the default values. If someone chooses to edit them directly, fine, their choice, but the recommended way would be to make those settings in OpenSim.ini or inimaster, leaving the config/* files untouched. This way, there would be no more *example files, no more merging and no more copying files just to make it run at all. Defaults in the code have been deemed to be impractical. Melanie Jeff Ames wrote: > Melanie wrote: >> I was suggesting to get away from *.example files. Instead, I am >> proposing to break up OpenSim.ini into *.ini files that provide the >> defaults. The in-code defaults are a requirement of Nini, but they >> are not functional, just ignore that they're there. The requirement >> for an OpenSim.ini file in code needs to be dropped, of course. > > It seems like our proposals are actually fairly similar. There has to > be some set of broken-up files with the .ini settings, which the > developers can update in SVN without fear of causing merge conflicts > for users. In your proposal, these are config/*.ini. In mine, > config/*.ini.example. > > Then there needs to be a place for users to make changes to the > default config. Yours is bin/OpenSim.ini, mine is config/*.ini. > >> That is why the config directory needs to be read first - it >> provides the defaults! Inimaster would be rendered useless by the >> load order you're proposing! > > I believe (at least I meant) that inimaster would function the same as > it does now. If inimaster says use ODE, then unless the user's local > config explicitly overrides that, the sim would use ODE. If neither > the inimaster or the local config say anything, OpenSim reverts to the > default basicphysics. > >> In your scenario, if the config/*.example changes, they'd still need >> to merge. > > If they copy the foo.ini.example to foo.ini, and then foo.ini.example > changes, then yes, they would have to find a way to integrate those > changes in foo.ini. If they only add what they're explicitly changing > to foo.ini, then the amount of merging would be reduced quite a bit. > > But unless I misunderstand what you mean by the merging problem, > there's no way to totally avoid it. The config files will change, and > users will have to integrate those changes somehow. (Can we do > migrations for .ini files?) > > I also think that having defaults in the code is useful, so that > external .ini files are not required. At the least, I'd like to have > a system where you could check out from SVN, build, and run, without > having to copy files around. > > Getting rid of the *.example files would be great, if we can. I > believe that the original reason for adding them wasn't avoiding merge > conflicts with users' configs (though that's nice), but to avoid > accidental commits of developers' configs to SVN. > > For a binary release, I think having only user-editable config/*.ini > files would make the most sense. But maybe how we handle .ini files > in SVN is necessarily more complicated. > > One option to remove the duplication, as well as avoiding these merge > conflicts, may be to keep the defaults in the code and generate the > config files programmatically, but that would likely take a bit of > tweaking, as I don't think Nini has any support for comments. > > Jeff > _______________________________________________ > Opensim-dev mailing list > Opensim-dev@lists.berlios.de > https://lists.berlios.de/mailman/listinfo/opensim-dev > > _______________________________________________ Opensim-dev mailing list Opensim-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev
