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
Lang Martin c22487c32b Decode into non-nil pointer's existing value.
Slight adaptation of Ian Remmler <ian@remmler.org>'s fix in pr #39:

> If decoding into a pointer, and the pointer points to a value, decode
> into the exitsing value.  Otherwise, decode into a new value and point
> to it.
> Addresses issue #38.
2019-04-25 16:13:25 -04:00
.github Add issue template 2016-10-08 11:43:23 +08:00
hcl fix unrelated parser_test compilation error 2019-04-25 15:35:19 -04:00
json fix typo 2017-10-17 10:11:56 -07:00
test-fixtures decoder_test check for decodedFields and unusedKeys 2019-04-05 12:49:19 -04:00
testhelper Support multiline string literals in HCL only in HIL fragments 2016-11-24 22:59:50 +03:00
.gitignore fix appveyor build 2016-02-29 23:04:50 -06:00
.travis.yml travis: update go versions 2017-10-09 10:47:08 -07:00
appveyor.yml Don't automatically convert to CRLF in AppVeyor 2016-12-01 12:09:33 -05:00
decoder_test.go Decode into non-nil pointer's existing value. 2019-04-25 16:13:25 -04:00
decoder.go Decode into non-nil pointer's existing value. 2019-04-25 16:13:25 -04:00
go.mod Prepare to be a Go module 2018-08-25 17:51:36 -07:00
go.sum Prepare to be a Go module 2018-08-25 17:51:36 -07:00
hcl_test.go Decode into flat structures for objects 2014-08-03 13:09:08 -07:00
hcl.go Use Go convention of docs with "Package" prefix 2015-11-26 14:57:49 +02:00
lex_test.go adds std encoding API fixes #4 2016-03-10 15:36:44 -05:00
lex.go adds std encoding API fixes #4 2016-03-10 15:36:44 -05:00
LICENSE
Makefile Update Makefile with new deps, go1.7 in travis 2016-09-16 08:54:14 -04:00
parse.go adds std encoding API fixes #4 2016-03-10 15:36:44 -05:00
README.md Added hcl to json example for nested objects (#36) 2016-09-02 11:46:43 -05:00

HCL

GoDoc Build Status

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 often 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

For a complete grammar, please see the parser itself. A high-level overview of the syntax and grammar is listed here.

  • Single line comments start with # or //

  • Multi-line comments are wrapped in /* and */. Nested block comments are not allowed. A multi-line comment (also known as a block comment) terminates at the first */ found.

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

  • Multi-line strings start with <<EOF at the end of a line, and end with EOF on its own line (here documents). Any text may be used in place of EOF. Example:

<<FOO
hello
world
FOO
  • 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, other arrays, and objects. As an alternative, lists of objects can be created with repeated blocks, using this structure:

    service {
        key = "value"
    }
    
    service {
        key = "value"
    }
    

Objects and nested objects are created using the structure shown below:

variable "ami" {
    description = "the AMI to use"
}

This would be equivalent to the following json:

{
  "variable": {
      "ami": {
          "description": "the AMI to use"
        }
    }
}

Thanks

Thanks to:

  • @vstakhov - The original libucl parser and syntax that HCL was based off of.

  • @fatih - The rewritten HCL parser in pure Go (no goyacc) and support for a printer.