|
From: Jason B. <jb...@ze...> - 2010-03-17 16:07:13
|
I'm not really sure how best to phrase my example, so I'll illustrate it
with code. :-)
Suppose I have the following config file:
[section]
foo='bar'
[[subsection]]
Now suppose I do the following:
configobj = <get configobj somehow>
subsection = configobj['section']['subsection']
subsection['foo']
This throws a key error, which is most likely the expected behavior as foo
isn't a key on subsection. However, I would like to have a way to get the
value of foo as if subsection were like this:
[[subsection]]
foo = '$foo'
That way I can fetch the value through the interpolation path rather than
only checking the current section. I suppose I could do something like
this:
try:
return subsection['foo']
except KeyError, ke:
subsection['foo'] = '$foo'
return subsection['foo']
But that feels a bit hacky. Are there any better ways to do this that I'm
not thinking of, or am I just going to have to buck up and put the hack in?
|
|
From: Michael F. <fuz...@vo...> - 2010-03-17 18:35:18
|
On 17/03/2010 15:42, Jason Baker wrote:
> I'm not really sure how best to phrase my example, so I'll illustrate
> it with code. :-)
>
> Suppose I have the following config file:
>
> [section]
> foo='bar'
> [[subsection]]
>
> Now suppose I do the following:
>
> configobj = <get configobj somehow>
> subsection = configobj['section']['subsection']
> subsection['foo']
>
> This throws a key error, which is most likely the expected behavior as
> foo isn't a key on subsection. However, I would like to have a way to
> get the value of foo as if subsection were like this:
>
> [[subsection]]
> foo = '$foo'
>
> That way I can fetch the value through the interpolation path rather
> than only checking the current section. I suppose I could do
> something like this:
>
> try:
> return subsection['foo']
> except KeyError, ke:
> subsection['foo'] = '$foo'
> return subsection['foo']
>
> But that feels a bit hacky. Are there any better ways to do this that
> I'm not thinking of, or am I just going to have to buck up and put the
> hack in?
How about setdefault?
>>> c = ConfigObj()
>>> c['bar'] = 'baz'
>>> c.setdefault('foo', '%(bar)s')
'baz'
Michael
>
> ------------------------------------------------------------------------------
> 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
>
--
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.
|
|
From: Jason B. <jb...@ze...> - 2010-03-17 18:50:21
|
On Wed, Mar 17, 2010 at 1:35 PM, Michael Foord <fuz...@vo...>wrote:
> How about setdefault?
>
> >>> c = ConfigObj()
> >>> c['bar'] = 'baz'
> >>> c.setdefault('foo', '%(bar)s')
> 'baz'
>
> Michael
>
I'm assuming you mean using setdefault in lieu of my exception handling
which is a good idea. However, the exception block isn't really my primary
concern. It just feels a bit like I'm coupling my app a bit too closely to
Section's inner workings by going that route. I was thinking of something
more along the lines of a magical "get_by_interpolation" function (or
something that would make implementing such a function easier). But, if
such an animal doesn't exist, I suppose I'll just have to deal. :-)
|
|
From: Michael F. <fuz...@vo...> - 2010-03-17 18:52:33
|
On 17/03/2010 18:50, Jason Baker wrote:
> On Wed, Mar 17, 2010 at 1:35 PM, Michael Foord
> <fuz...@vo... <mailto:fuz...@vo...>> wrote:
>
> How about setdefault?
>
> >>> c = ConfigObj()
> >>> c['bar'] = 'baz'
> >>> c.setdefault('foo', '%(bar)s')
> 'baz'
>
> Michael
>
>
> I'm assuming you mean using setdefault in lieu of my exception
> handling which is a good idea. However, the exception block isn't
> really my primary concern. It just feels a bit like I'm coupling my
> app a bit too closely to Section's inner workings by going that
> route. I was thinking of something more along the lines of a magical
> "get_by_interpolation" function (or something that would make
> implementing such a function easier). But, if such an animal doesn't
> exist, I suppose I'll just have to deal. :-)
Well - as far as I can tell setdefault is exactly a "magical
get_by_interpolation function" - so I guess I'm not understanding you
(setdefault is also a standard dictionary method).
Michael
--
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.
|
|
From: Jason B. <jb...@ze...> - 2010-03-17 19:53:12
|
On Wed, Mar 17, 2010 at 1:52 PM, Michael Foord <fuz...@vo...>wrote:
> Well - as far as I can tell setdefault is exactly a "magical
> get_by_interpolation function" - so I guess I'm not understanding you
> (setdefault is also a standard dictionary method).
>
> Michael
>
Consider the following config file:
[section]
foo = 'bar'
[[subsection]]
baz = '$foo'
Suppose I have a Section object that represents the subsection
(configobj['section']['subsection']). Now suppose I do this:
a = subsection['baz']
Since the option baz contains a string '$foo', what happens is something
like the following:
1. The interpolater looks in subsection to see if it has a foo option.
2. When it sees that it doesn't exist, it checks the DEFAULT section.
3. When it sees that *that* doesn't exist, it checks the parent section
4. The parent section has a foo option, so it returns it.
Now suppose I do this:
b = subsection['foo']
What happens is more like the following:
1. Subsection is searched for a foo option.
2. Subsection doesn't have a foo option, so it throws a KeyError.
What I would like is some kind of function such that I can do something like
this:
c = subsection.get_by_interpolation('foo')
...that would look for an option named foo, but would look in the same
places as the first operation. Here's the reason why I want to do this.
Using envbuilder, I want to write a config file like this:
[project]
parcel = 'parcel1', 'parcel2'
[[DEFAULT]]
branch = 'master'
[[parcel1]]
[[parcel2]]
branch = 'someotherbranch'
[commands]
[[update]]
default = 'git pull origin %branch'
Essentially, I've written my own interpolation engine for commands such that
a variable beginning with % is to be on the parcel. So when I run "envb
update", it should essentially run:
# Get parcel1 using branch from default
$ git pull origin master
# Get parcel2 using branch from parcel2
$ git pull origin someotherbranch
However, parcel1 would throw an exception because it doesn't actually have
an option named "branch". Of course, I could do something like this:
[project]
parcels = 'parcel1', 'parcel2'
[[DEFAULT]]
default_branch = 'master'
[[parcel1]]
branch = '$default_branch'
[[parcel2]]
branch = 'someotherbranch'
[commands]
[[update]]
default = 'git pull origin %branch'
...but that gets tedious when you start dealing with a nontrivial amount of
parcels.
Does that make things more clear, or did I just confuse you even more? :-)
|
|
From: Entity R. <ent...@gm...> - 2010-03-17 22:24:05
|
On Wed, 2010-03-17 at 14:53 -0500, Jason Baker wrote:
> On Wed, Mar 17, 2010 at 1:52 PM, Michael Foord
> <fuz...@vo...> wrote:
>
>
> Well - as far as I can tell setdefault is exactly a "magical
> get_by_interpolation function" - so I guess I'm not
> understanding you (setdefault is also a standard dictionary
> method).
>
> Michael
>
> Consider the following config file:
>
> [section]
> foo = 'bar'
> [[subsection]]
> baz = '$foo'
>
> Suppose I have a Section object that represents the subsection
> (configobj['section']['subsection']). Now suppose I do this:
>
> a = subsection['baz']
>
> Since the option baz contains a string '$foo', what happens is
> something like the following:
>
> 1. The interpolater looks in subsection to see if it has a foo
> option.
> 2. When it sees that it doesn't exist, it checks the DEFAULT section.
> 3. When it sees that *that* doesn't exist, it checks the parent
> section
> 4. The parent section has a foo option, so it returns it.
>
> Now suppose I do this:
>
> b = subsection['foo']
>
> What happens is more like the following:
>
> 1. Subsection is searched for a foo option.
> 2. Subsection doesn't have a foo option, so it throws a KeyError.
>
> What I would like is some kind of function such that I can do
> something like this:
>
> c = subsection.get_by_interpolation('foo')
>
> ...that would look for an option named foo, but would look in the same
> places as the first operation. Here's the reason why I want to do
> this. Using envbuilder, I want to write a config file like this:
>
> [project]
> parcel = 'parcel1', 'parcel2'
>
> [[DEFAULT]]
> branch = 'master'
>
> [[parcel1]]
>
> [[parcel2]]
> branch = 'someotherbranch'
>
> [commands]
> [[update]]
> default = 'git pull origin %branch'
>
> Essentially, I've written my own interpolation engine for commands
> such that a variable beginning with % is to be on the parcel. So when
> I run "envb update", it should essentially run:
>
> # Get parcel1 using branch from default
> $ git pull origin master
>
> # Get parcel2 using branch from parcel2
> $ git pull origin someotherbranch
>
> However, parcel1 would throw an exception because it doesn't actually
> have an option named "branch". Of course, I could do something like
> this:
>
> [project]
> parcels = 'parcel1', 'parcel2'
>
> [[DEFAULT]]
> default_branch = 'master'
>
> [[parcel1]]
> branch = '$default_branch'
>
> [[parcel2]]
> branch = 'someotherbranch'
>
> [commands]
> [[update]]
> default = 'git pull origin %branch'
>
> ...but that gets tedious when you start dealing with a nontrivial
> amount of parcels.
>
> Does that make things more clear, or did I just confuse you even
> more? :-)
>
> ------------------------------------------------------------------------------
> 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
I as well am interested in this. Auto-interpolation of a tree of
sections. Or rather, start from a specified branch, and then percolate
towards the trunk until a valid variable is found.
My Example: (IRC Bot)
[servers]
nick = BarBaz
# ...
[[Freenode]]
nick = FooBar
# ...
[[EFNet]]
# ...
config['servers']['EFNet'] (or some similar syntax) would return
"BarBaz"
|
|
From: David H. <neg...@gm...> - 2010-03-18 14:38:48
|
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.
cheers,
-David
On Wed, Mar 17, 2010 at 18:23, Entity Reborn <ent...@gm...> wrote:
>
> On Wed, 2010-03-17 at 14:53 -0500, Jason Baker wrote:
> > On Wed, Mar 17, 2010 at 1:52 PM, Michael Foord
> > <fuz...@vo...> wrote:
> >
> >
> > Well - as far as I can tell setdefault is exactly a "magical
> > get_by_interpolation function" - so I guess I'm not
> > understanding you (setdefault is also a standard dictionary
> > method).
> >
> > Michael
> >
> > Consider the following config file:
> >
> > [section]
> > foo = 'bar'
> > [[subsection]]
> > baz = '$foo'
> >
> > Suppose I have a Section object that represents the subsection
> > (configobj['section']['subsection']). Now suppose I do this:
> >
> > a = subsection['baz']
> >
> > Since the option baz contains a string '$foo', what happens is
> > something like the following:
> >
> > 1. The interpolater looks in subsection to see if it has a foo
> > option.
> > 2. When it sees that it doesn't exist, it checks the DEFAULT section.
> > 3. When it sees that *that* doesn't exist, it checks the parent
> > section
> > 4. The parent section has a foo option, so it returns it.
> >
> > Now suppose I do this:
> >
> > b = subsection['foo']
> >
> > What happens is more like the following:
> >
> > 1. Subsection is searched for a foo option.
> > 2. Subsection doesn't have a foo option, so it throws a KeyError.
> >
> > What I would like is some kind of function such that I can do
> > something like this:
> >
> > c = subsection.get_by_interpolation('foo')
> >
> > ...that would look for an option named foo, but would look in the same
> > places as the first operation. Here's the reason why I want to do
> > this. Using envbuilder, I want to write a config file like this:
> >
> > [project]
> > parcel = 'parcel1', 'parcel2'
> >
> > [[DEFAULT]]
> > branch = 'master'
> >
> > [[parcel1]]
> >
> > [[parcel2]]
> > branch = 'someotherbranch'
> >
> > [commands]
> > [[update]]
> > default = 'git pull origin %branch'
> >
> > Essentially, I've written my own interpolation engine for commands
> > such that a variable beginning with % is to be on the parcel. So when
> > I run "envb update", it should essentially run:
> >
> > # Get parcel1 using branch from default
> > $ git pull origin master
> >
> > # Get parcel2 using branch from parcel2
> > $ git pull origin someotherbranch
> >
> > However, parcel1 would throw an exception because it doesn't actually
> > have an option named "branch". Of course, I could do something like
> > this:
> >
> > [project]
> > parcels = 'parcel1', 'parcel2'
> >
> > [[DEFAULT]]
> > default_branch = 'master'
> >
> > [[parcel1]]
> > branch = '$default_branch'
> >
> > [[parcel2]]
> > branch = 'someotherbranch'
> >
> > [commands]
> > [[update]]
> > default = 'git pull origin %branch'
> >
> > ...but that gets tedious when you start dealing with a nontrivial
> > amount of parcels.
> >
> > Does that make things more clear, or did I just confuse you even
> > more? :-)
> >
> > ------------------------------------------------------------------------------
> > 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
>
> I as well am interested in this. Auto-interpolation of a tree of
> sections. Or rather, start from a specified branch, and then percolate
> towards the trunk until a valid variable is found.
>
> My Example: (IRC Bot)
> [servers]
> nick = BarBaz
> # ...
> [[Freenode]]
> nick = FooBar
> # ...
> [[EFNet]]
> # ...
>
> config['servers']['EFNet'] (or some similar syntax) would return
> "BarBaz"
>
>
> ------------------------------------------------------------------------------
> 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
|
|
From: Jason B. <jb...@ze...> - 2010-03-18 16:06:29
|
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? :-) |
|
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 > > |
|
From: Jason B. <jb...@ze...> - 2010-03-18 17:47:08
|
On Thu, Mar 18, 2010 at 11:20 AM, David Hostetler <neg...@gm...>wrote: > 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 > > It's this. :-) |