b699557f16
/cc @armon - This changes how Consul has to define its structure. Ping me tomorrow to learn more, but going to leave it here for reference too: The Consul case (there is a test case) never worked even with go-libucl, because there is an ambiguity of whether you want the inner children or the array of outer elements (the slice in the Policy struct). I've added a new modifier you can specify with a tag called "expand" which will tell hcl to expand the value to its children for decoding. You can see me use it in the test case which verifies that the Consul ACLs parse. |
||
|---|---|---|
| hcl | ||
| json | ||
| test-fixtures | ||
| .gitignore | ||
| decoder_test.go | ||
| decoder.go | ||
| hcl_test.go | ||
| hcl.go | ||
| lex_test.go | ||
| lex.go | ||
| LICENSE | ||
| Makefile | ||
| parse.go | ||
| README.md | ||
HCL
HCL (HashiCorp Configuration Language) is a configuration language built by HashiCorp. The goal of HCL is to build a structured configuration language that is both human and machine friendly for use with command-line tools, but specifically targeted towards DevOps tools, servers, etc.
HCL is also fully JSON compatible. That is, JSON can be used as completely valid input to a system expecting HCL. This helps makes systems interoperable with other systems.
HCL is heavily inspired by libucl, nginx configuration, and others similar.
Why?
A common question when viewing HCL is to ask the question: why not JSON, YAML, etc.?
Prior to HCL, the tools we built at HashiCorp used a variety of configuration languages from full programming languages such as Ruby to complete data structure languages such as JSON. What we learned is that some people wanted human-friendly configuration languages and some people wanted machine-friendly languages.
JSON fits a nice balance in this, but is fairly verbose and most importantly doesn't support comments. With YAML, we found that beginners had a really hard time determining what the actual structure was, and ended up guessing more than not whether to use a hyphen, colon, etc. in order to represent some configuration key.
Full programming languages such as Ruby enable complex behavior a configuration language shouldn't usually allow, and also forces people to learn some set of Ruby.
Because of this, we decided to create our own configuration language that is JSON-compatible. Our configuration language (HCL) is designed to be written and modified by humans. The API for HCL allows JSON as an input so that it is also machine-friendly (machines can generate JSON instead of trying to generate HCL).
Our goal with HCL is not to alienate other configuration languages. It is instead to provide HCL as a specialized language for our tools, and JSON as the interoperability layer.
Syntax
The complete grammar can be found here, if you're more comfortable reading specifics, but a high-level overview of the syntax and grammar are listed here.
-
Single line comments start with
#or// -
Multi-line comments are wrapped in
/*and*/ -
Values are assigned with the syntax
key = value(whitespace doesn't matter). The value can be any primitive: a string, number, boolean, object, or list. -
Strings are double-quoted and can contain any UTF-8 characters. Example:
"Hello, World" -
Numbers are assumed to be base 10. If you prefix a number with 0x, it is treated as a hexadecimal. If it is prefixed with 0, it is treated as an octal.
-
Boolean values:
true,false,on,off,yes,no. -
Arrays can be made by wrapping it in
[]. Example:["foo", "bar", 42]. Arrays can contain primitives and other arrays, but cannot contain objects. Objects must use the block syntax shown below.
Objects and nested objects are created using the structure shown below:
variable "ami" {
description = "the AMI to use"
}