atom feed7 messages in org.boxgrinder.boxgrinder-devRe: [boxgrinder-dev] Removing custom ...
FromSent OnAttachments
Marek GoldmannDec 9, 2011 1:16 am 
Marek GoldmannDec 9, 2011 3:27 am 
Bright FultonDec 9, 2011 5:17 am 
Marc SavyDec 9, 2011 5:21 am 
Bright FultonDec 9, 2011 7:18 am 
Marc SavyDec 14, 2011 7:37 am 
Sergio RubioDec 15, 2011 2:33 am 
Subject:Re: [boxgrinder-dev] Removing custom variables
From:Marc Savy (
Date:Dec 14, 2011 7:37:28 am

The feature is done for the upcoming 0.10.0 release :-)! The other non-functional bits can wait for the next release [0].

So in brief, it works as follows: 1. Look up pre-defined variables (such as #BASE_ARCH#), or appliance defined variables (var section). 2. Look into environment (e.g. `export MY_VAR='something'` => #MY_VAR#)

As a bonus we've added recursive/nested variable resolution, so in a pseudo-code way, the following would work fine [1]:

#VAR_A# => "#VAR_B#" #VAR_B# => "#VAR_C# #VAR_D# #VAR_E#!" #VAR_C# => "Hello" #VAR_D# => "BoxGrinder" #VAR_E# => "World"

Just a final note, remember to put any strings that use variables in quotes, or they will be parsed as comments!

Example: - "Hello-#VAR_A#" -- Good, this will resolve properly. - Hello-#Var_A# -- Bad, this will end up as just 'Hello-'.


[0] There are several instances where we have a merge/override hierarchies such as `repos`, and there is no point having separate code to perform an essentially generic function.

[1] It'll bottom out after a depth of 20, which would probably suggest that you have made a loop :o).

[2] We will clarify the docs soon!

On 09/12/2011 15:19, Bright Fulton wrote:

Marc, agree. And the fallback to ENV lookup is a cool addition.

Marek, everyone, please let me know if you would like help testing or implementing any changes.


On Fri, Dec 9, 2011 at 8:22 AM, Marc Savy<> wrote:

On 09/12/2011 13:18, Bright Fulton wrote:

I contributed custom variables and use them for "baking not frying". A typical use case is to mix-in tier-specific vars (which update server to talk to, a vhost name, a public key, an override to a default value, an arbitrary block for a config file) from staging.appl or production.appl.

If variables are removed, I may go to templated and generated appls as some others who were not aware of variables have done, but having them integral allows for an overlay inheritance which mirrors how they are used (in post sections). ENV[] would be insufficient for this.


I think my opinion aligns with this.

IMO we should leave them in, and use the approach I outlined in my proposal; first use variables defined in appliance (or pre-defined), look into the environment if there is no definition.

On Dec 9, 2011, at 4:17 AM, Marek Goldmann<> wrote:

Hi all,

I would like to gather your comments on removing a feature from BoxGrinder. Some time ago I pulled a commit from one of our community members adding support for specifying custom variables in .appl files:

The code sits now here:

Question is - do you think having custom variables in .appl make sense? If yes, please feed me with some use cases.

I think it's worth mentioning also that thank to Marc we are now able to resolve our default variables (OS_NAME, OS_VERSION, ARCH, BASE_ARCH) in any part of .appl file. For more info take a look here: