go/hcl
2
0
Fork 0
Code Issues Pull Requests Releases Wiki Activity
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
380 Commits 1 Branch 1 Tag 2.5 MiB
Go 83.7%
Ragel 10.2%
reStructuredText 4.4%
Ruby 0.5%
Python 0.3%
Other 0.8%
3ad5dd62fd
Go to file
James Nugent 3ad5dd62fd Add support for indented HEREDOC terminators 
This PR adds support for the style of HEREDOC often used in Ruby which
allows the terminating marker to be indented if the HEREDOC is started
with the sequence "<<-" rather than the usual "<<". This allows users to
express documents with more natural indentation:

resource "template_file" "test" {
    template = <<-HEREDOC
        First Line
        Second Line
    HEREDOC
}

Note that this does not attempt to add any semantics around removing
hanging indent from the actual text of the document, so extra
indentation would still be present. We could make use of the canonical
style for HCL herre to remove the hanging indent in the style of Ruby
which would probably be more predictable for users.
2016-03-21 14:12:20 +00:00
hcl Add support for indented HEREDOC terminators 2016-03-21 14:12:20 +00:00
json Fix flattening of empty objects 2015-11-20 17:56:37 +01:00
test-fixtures Add support for indented HEREDOC terminators 2016-03-21 14:12:20 +00:00
testhelper Fix scanner tests on Windows 2016-03-20 23:14:42 +00:00
.gitignore fix appveyor build 2016-02-29 23:04:50 -06:00
.travis.yml Add travis.yml file 2015-11-12 17:56:38 +02:00
appveyor.yml Fix the appveyor build script 2016-03-21 00:09:29 +00:00
decoder_test.go Add support for indented HEREDOC terminators 2016-03-21 14:12:20 +00:00
decoder.go Return an error if object keys are not strings 2016-03-21 13:32:31 +00: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 LICENSE 2014-07-31 12:49:17 -07:00
Makefile hcl: use stringer to generate string values for ValueType 2015-01-15 15:12:25 -08:00
parse.go adds std encoding API fixes #4 2016-03-10 15:36:44 -05:00
README.md added missing word 2016-03-18 09:56:42 +01:00

README.md

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

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.