|
From: David H. <neg...@gm...> - 2010-03-18 16:20:57
|
Unless I'm mistaken, validation only validates what is explicitly in the spec. Anything else passes through untouched. So as long as the "crazy stuff you didn't anticipate" doesn't violate the basic configobj syntax, it'd end up in the resulting ConfigObj. Or do you mean that you want even the crazy unanticipated stuff to get automatic fall-through interpolation-style defaulting? In which case, yeah, the validation approach isn't suitable, because the interpolation reference has to be represented in the spec. -David On Thu, Mar 18, 2010 at 12:06, Jason Baker <jb...@ze...> wrote: > On Thu, Mar 18, 2010 at 9:38 AM, David Hostetler <neg...@gm...> > wrote: >> >> Is there some reason you can't use validate to set the default? >> >> Consider the following validation spec: >> >> [project] >> parcels = string_list() >> >> [[DEFAULT]] >> default_branch = string() >> >> [[__many__]] >> branch = string(default=$default_branch) >> >> >> Applied to the following config: >> >> [project] >> parcels = parcel1,parcel2 >> >> [[DEFAULT]] >> default_branch = master >> >> [[parcel1]] >> >> [[parcel2]] >> branch = someotherbranch >> >> >> Now when you parse the config, and validate it against the spec, you >> get the following: >> >> >> cfg['project']['parcel1']['branch'] >> >> 'master' >> >> >> >> cfg['project']['parcel2']['branch'] >> >> 'someotherbranch' >> >> >> No hackery. And you get the usual added benefits of validation. > > TL;DR - I have philosophical issues that prevent me from going that route. > > This actually brings up a good point though. Essentially, my goal in > creating envbuilder is to have a build system that's flexible enough to > adapt to what the user is trying to use it for. The above requires me to > know what options the user is looking for beforehand and code them in the > configspec. This limits the amount of crazy stuff I didn't anticipate that > a user can do. > > In that vein, envbuilder can currently handle any VCS that has a > command-line interface. The above might be sensible for git, but does it > work for hg or bzr or fossil or CVS? :-) > > ------------------------------------------------------------------------------ > Download Intel® Parallel Studio Eval > Try the new software tools for yourself. Speed compiling, find bugs > proactively, and fine-tune applications for parallel performance. > See why Intel Parallel Studio got high marks during beta. > http://p.sf.net/sfu/intel-sw-dev > _______________________________________________ > Configobj-develop mailing list > Con...@li... > https://lists.sourceforge.net/lists/listinfo/configobj-develop > > |