configobj-develop

[Configobj-develop] How do I access options from across sections?

[Jason B. <amn...@gm...>]

I'm using configobj for envbuilder[1].  There's one place where I'm a
bit stuck and I'm curious if there's any way around it.  Essentially,
I have a section that defines a set of packages (parcels) to be
checked out from SCM, and another section that defines commands to be
run against all parcels.  Here's the example from the readme:

[project]
parcels = 'envbuilder', # Note the comma

    [[DEFAULT]]
    git_checkout = 'git clone $url'
    cwd = '/home/jason/src/envbuilder-src'
    python = '$cwd/bin/python'

    [[envbuilder]]
    dir = 'envbuilder'
    url = 'git://github.com/jasonbaker/envbuilder.git'
    setup = '$python setup.py develop'
    checkout = '$git_checkout'

[commands]
    [[ status ]]
    required = True
    default = 'git status'
    working_dir = '$$PARCEL_WD'
    help = 'Check the status of all checked-out parcels'

The working_dir's value of $$PARCEL_WD is a bit of a hack.  I just go
in and substitute the parcel's working directory for $PARCEL_WD
*after* interpolation has already run.  What would be nice is if I
could access the parcel's option dir.  Bear in mind that since parcels
are defined as a __many__ subsection, I need to get the value for
*each* parcel.

I understand that this will likely require me to write some code
somewhere (either in configobj or in envbuilder), but can someone help
me figure out the best way to go about solving this problem?

[1] http://github.com/jasonbaker/envbuilder

Re: [Configobj-develop] How do I access options from across sections?

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

On 24/01/2010 13:11, Jason Baker wrote:
> I'm using configobj for envbuilder[1].  There's one place where I'm a
> bit stuck and I'm curious if there's any way around it.  Essentially,
> I have a section that defines a set of packages (parcels) to be
> checked out from SCM, and another section that defines commands to be
> run against all parcels.  Here's the example from the readme:
>    

Heh. I don't have any brilliant ideas - a phase of post-processing 
sounds like the best way to me.

All the best,

Michael

> [project]
> parcels = 'envbuilder', # Note the comma
>
>      [[DEFAULT]]
>      git_checkout = 'git clone $url'
>      cwd = '/home/jason/src/envbuilder-src'
>      python = '$cwd/bin/python'
>
>      [[envbuilder]]
>      dir = 'envbuilder'
>      url = 'git://github.com/jasonbaker/envbuilder.git'
>      setup = '$python setup.py develop'
>      checkout = '$git_checkout'
>
> [commands]
>      [[ status ]]
>      required = True
>      default = 'git status'
>      working_dir = '$$PARCEL_WD'
>      help = 'Check the status of all checked-out parcels'
>
> The working_dir's value of $$PARCEL_WD is a bit of a hack.  I just go
> in and substitute the parcel's working directory for $PARCEL_WD
> *after* interpolation has already run.  What would be nice is if I
> could access the parcel's option dir.  Bear in mind that since parcels
> are defined as a __many__ subsection, I need to get the value for
> *each* parcel.
>
> I understand that this will likely require me to write some code
> somewhere (either in configobj or in envbuilder), but can someone help
> me figure out the best way to go about solving this problem?
>
> [1] http://github.com/jasonbaker/envbuilder
>
> ------------------------------------------------------------------------------
> Throughout its 18-year history, RSA Conference consistently attracts the
> world's best and brightest in the field, creating opportunities for Conference
> attendees to learn about information security's most important issues through
> interactions with peers, luminaries and emerging and established companies.
> http://p.sf.net/sfu/rsaconf-dev2dev
> _______________________________________________
> 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.

Re: [Configobj-develop] How do I access options from across sections?

[Jason B. <amn...@gm...>]

On Sun, Jan 24, 2010 at 1:32 PM, Michael Foord
<fuz...@vo...> wrote:
> On 24/01/2010 13:11, Jason Baker wrote:
>> I'm using configobj for envbuilder[1].  There's one place where I'm a
>> bit stuck and I'm curious if there's any way around it.  Essentially,
>> I have a section that defines a set of packages (parcels) to be
>> checked out from SCM, and another section that defines commands to be
>> run against all parcels.  Here's the example from the readme:
>>
>
> Heh. I don't have any brilliant ideas - a phase of post-processing
> sounds like the best way to me.

The solution that I ended up implementing is actually pretty simple.
I decided that parcel options should be delimited by a % instead of a
$, and I just run my own Template sub-class over the strings (so now I
can get rid of the ugly $$PARCEL_WD hack).

Thanks for the help, guys!

Re: [Configobj-develop] How do I access options from across sections?

[David H. <neg...@gm...>]

Hey Jason,

I certainly don't think new code in configobj is the way to accomplish what
you describe.

The 'status' subsection  in the 'commands' section is (as I read it) a
recipe that gets applied programmatically at runtime against a set of
multiple blocks of recipe input.  I.e. - you apply the 'status' operation to
every parcel described in the 'project' section (explicitly listed by the
'parcels' entry).

But from a configuration standpoint, 'status' is ONE block, and the parcels
are MANY blocks.  You cannot have a command be both generic and
simultaneously reflective of explicit values in every entry in the list of
parcel data.  More specifically: working_dir cannot be set to more than one
cwd value at any given time anyway, so I'm confused what kind of meaningful
thing you think ConfigObj could do in this scenario anyway.

But more to the point: why does it need to?  You have everything you need
already.  Rather than having:

working_dir = '$$PARCEL_WD', why not have:

working_dir = 'cwd'

Thus working_dir becomes a mapping, telling you what keyword in any given
parcel contains the information you need for the command's keyword.  I.e.
it's just a one-level indirection mechanism.

Once your program has digested the config data at runtime, you presumably
iterate over all of the commands, on all of the parcels.  So it might look
something like:

for cmd in cfg['commands'].keys():
    for parcel in cfg['project']['parcels']:
        cwd = cfg['project'][parcel][cfg['commands'][cmd]['working_dir']]
        <...do stuff...>

And note that even this is only necessary if the command config requires a
'working_dir' keyword instead of just 'cwd'.   Because otherwise, you don't
even need the mapping.  A command's config section provides the information
necessary to uniquely define it, and you fill in any missing values that
originate from a parcel config block by using the keyword:value pairs
directly from the parcel's config data!

ConfigObj (and configuration parsing in general) provides error-checking,
sanitation, and defaulting.  It doesn't (and shouldn't) provide program
logic.

regards,

-David


On Sun, Jan 24, 2010 at 08:11, Jason Baker <amn...@gm...> wrote:

> I'm using configobj for envbuilder[1].  There's one place where I'm a
> bit stuck and I'm curious if there's any way around it.  Essentially,
> I have a section that defines a set of packages (parcels) to be
> checked out from SCM, and another section that defines commands to be
> run against all parcels.  Here's the example from the readme:
>
> [project]
> parcels = 'envbuilder', # Note the comma
>
>    [[DEFAULT]]
>    git_checkout = 'git clone $url'
>    cwd = '/home/jason/src/envbuilder-src'
>    python = '$cwd/bin/python'
>
>    [[envbuilder]]
>    dir = 'envbuilder'
>    url = 'git://github.com/jasonbaker/envbuilder.git'
>    setup = '$python setup.py develop'
>    checkout = '$git_checkout'
>
> [commands]
>    [[ status ]]
>    required = True
>    default = 'git status'
>    working_dir = '$$PARCEL_WD'
>    help = 'Check the status of all checked-out parcels'
>
> The working_dir's value of $$PARCEL_WD is a bit of a hack.  I just go
> in and substitute the parcel's working directory for $PARCEL_WD
> *after* interpolation has already run.  What would be nice is if I
> could access the parcel's option dir.  Bear in mind that since parcels
> are defined as a __many__ subsection, I need to get the value for
> *each* parcel.
>
> I understand that this will likely require me to write some code
> somewhere (either in configobj or in envbuilder), but can someone help
> me figure out the best way to go about solving this problem?
>
> [1] http://github.com/jasonbaker/envbuilder
>
>
> ------------------------------------------------------------------------------
> Throughout its 18-year history, RSA Conference consistently attracts the
> world's best and brightest in the field, creating opportunities for
> Conference
> attendees to learn about information security's most important issues
> through
> interactions with peers, luminaries and emerging and established companies.
> http://p.sf.net/sfu/rsaconf-dev2dev
> _______________________________________________
> Configobj-develop mailing list
> Con...@li...
> https://lists.sourceforge.net/lists/listinfo/configobj-develop
>