fork of https://github.com/hashicorp/hcl because issue : https://github.com/hashicorp/hcl/issues/290 these code permit use of "nested" field decoding which is just composite struct
Go to file
2014-12-24 17:49:50 -05:00
hcl Modified to import github.com/hashicorp/go-multierror rather than terraform's multierror. 2014-12-24 17:49:50 -05:00
json json: true, false, null lex [GH-22] 2014-11-21 10:59:12 -08:00
test-fixtures parse floats 1.02 properly [GH-19] 2014-11-12 21:29:07 -08:00
.gitignore JSON parser 2014-08-02 11:38:41 -07:00
decoder_test.go parse floats 1.02 properly [GH-19] 2014-11-12 21:29:07 -08:00
decoder.go decoder: fix format error due to invalid argument (byte to string) 2014-11-02 12:57:26 +01:00
hcl_test.go Decode into flat structures for objects 2014-08-03 13:09:08 -07:00
hcl.go hcl: docs 2014-08-03 13:45:46 -07:00
lex_test.go Empty files are HCL 2014-09-15 09:40:47 -07:00
lex.go Empty files are HCL 2014-09-15 09:40:47 -07:00
LICENSE LICENSE 2014-07-31 12:49:17 -07:00
Makefile Decode into flat structures for objects 2014-08-03 13:09:08 -07:00
parse.go compiles, all tests failing 2014-08-11 16:33:28 -07:00
README.md Update README.md 2014-10-15 20:29:50 -07:00

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. Numbers can be in scientific notation: "1e10".

  • Boolean values: true, false

  • 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"
}