YAML support for the Go language

YAML support for the Go language

PkgGoDev Go codecov Go Report Card

Why a new library?

As of this writing, there already exists a de facto standard library for YAML processing for Go: https://github.com/go-yaml/yaml. However we feel that some features are lacking, namely:

  • Pretty format for error notifications
  • Direct manipulation of YAML abstract syntax tree
  • Support for Anchor and Alias when marshaling
  • Allow referencing elements declared in another file via anchors

Features

  • Pretty format for error notifications
  • Supports Scanner or Lexer or Parser as public API
  • Supports Anchor and Alias to Marshaler
  • Allow referencing elements declared in another file via anchors
  • Extract value or AST by YAMLPath ( YAMLPath is like a JSONPath )

Installation

go get -u github.com/goccy/go-yaml

Synopsis

1. Simple Encode/Decode

Has an interface like go-yaml/yaml using reflect

var v struct {
	A int
	B string
}
v.A = 1
v.B = "hello"
bytes, err := yaml.Marshal(v)
if err != nil {
	//...
}
fmt.Println(string(bytes)) // "a: 1\nb: hello\n"
	yml := `
%YAML 1.2
---
a: 1
b: c
`
var v struct {
	A int
	B string
}
if err := yaml.Unmarshal([]byte(yml), &v); err != nil {
	//...
}

To control marshal/unmarshal behavior, you can use the yaml tag.

	yml := `---
foo: 1
bar: c
`
var v struct {
	A int    `yaml:"foo"`
	B string `yaml:"bar"`
}
if err := yaml.Unmarshal([]byte(yml), &v); err != nil {
	//...
}

For convenience, we also accept the json tag. Note that not all options from the json tag will have significance when parsing YAML documents. If both tags exist, yaml tag will take precedence.

	yml := `---
foo: 1
bar: c
`
var v struct {
	A int    `json:"foo"`
	B string `json:"bar"`
}
if err := yaml.Unmarshal([]byte(yml), &v); err != nil {
	//...
}

For custom marshal/unmarshaling, implement either Bytes or Interface variant of marshaler/unmarshaler. The difference is that while BytesMarshaler/BytesUnmarshaler behaves like encoding/json and InterfaceMarshaler/InterfaceUnmarshaler behaves like gopkg.in/yaml.v2.

Semantically both are the same, but they differ in performance. Because indentation matters in YAML, you cannot simply accept a valid YAML fragment from a Marshaler, and expect it to work when it is attached to the parent container's serialized form. Therefore when we receive use the BytesMarshaler, which returns []byte, we must decode it once to figure out how to make it work in the given context. If you use the InterfaceMarshaler, we can skip the decoding.

If you are repeatedly marshaling complex objects, the latter is always better performance wise. But if you are, for example, just providing a choice between a config file format that is read only once, the former is probably easier to code.

2. Reference elements declared in another file

testdata directory contains anchor.yml file:

├── testdata
   └── anchor.yml

And anchor.yml is defined as follows:

a: &a
  b: 1
  c: hello

Then, if yaml.ReferenceDirs("testdata") option is passed to yaml.Decoder, Decoder tries to find the anchor definition from YAML files the under testdata directory.

buf := bytes.NewBufferString("a: *a\n")
dec := yaml.NewDecoder(buf, yaml.ReferenceDirs("testdata"))
var v struct {
	A struct {
		B int
		C string
	}
}
if err := dec.Decode(&v); err != nil {
	//...
}
fmt.Printf("%+v\n", v) // {A:{B:1 C:hello}}

3. Encode with Anchor and Alias

3.1. Explicitly declared Anchor name and Alias name

If you want to use anchor or alias, you can define it as a struct tag.

type T struct {
  A int
  B string
}
var v struct {
  C *T `yaml:"c,anchor=x"`
  D *T `yaml:"d,alias=x"`
}
v.C = &T{A: 1, B: "hello"}
v.D = v.C
bytes, err := yaml.Marshal(v)
if err != nil {
  panic(err)
}
fmt.Println(string(bytes))
/*
c: &x
  a: 1
  b: hello
d: *x
*/

3.2. Implicitly declared Anchor and Alias names

If you do not explicitly declare the anchor name, the default behavior is to use the equivalent of strings.ToLower($FieldName) as the name of the anchor.

If you do not explicitly declare the alias name AND the value is a pointer to another element, we look up the anchor name by finding out which anchor field the value is assigned to by looking up its pointer address.

type T struct {
	I int
	S string
}
var v struct {
	A *T `yaml:"a,anchor"`
	B *T `yaml:"b,anchor"`
	C *T `yaml:"c,alias"`
	D *T `yaml:"d,alias"`
}
v.A = &T{I: 1, S: "hello"}
v.B = &T{I: 2, S: "world"}
v.C = v.A // C has same pointer address to A
v.D = v.B // D has same pointer address to B
bytes, err := yaml.Marshal(v)
if err != nil {
	//...
}
fmt.Println(string(bytes)) 
/*
a: &a
  i: 1
  s: hello
b: &b
  i: 2
  s: world
c: *a
d: *b
*/

3.3 MergeKey and Alias

Merge key and alias ( <<: *alias ) can be used by embedding a structure with the inline,alias tag.

type Person struct {
	*Person `yaml:",omitempty,inline,alias"` // embed Person type for default value
	Name    string `yaml:",omitempty"`
	Age     int    `yaml:",omitempty"`
}
defaultPerson := &Person{
	Name: "John Smith",
	Age:  20,
}
people := []*Person{
	{
		Person: defaultPerson, // assign default value
		Name:   "Ken",         // override Name property
		Age:    10,            // override Age property
	},
	{
		Person: defaultPerson, // assign default value only
	},
}
var doc struct {
	Default *Person   `yaml:"default,anchor"`
	People  []*Person `yaml:"people"`
}
doc.Default = defaultPerson
doc.People = people
bytes, err := yaml.Marshal(doc)
if err != nil {
	//...
}
fmt.Println(string(bytes))
/*
default: &default
  name: John Smith
  age: 20
people:
- <<: *default
  name: Ken
  age: 10
- <<: *default
*/

4. Pretty Formatted Errors

Error values produced during parsing have two extra features over regular error values.

First, by default, they contain extra information on the location of the error from the source YAML document, to make it easier to find the error location.

Second, the error messages can optionally be colorized.

If you would like to control exactly how the output looks like, consider using yaml.FormatError, which accepts two boolean values to control turning these features on or off.

5. Use YAMLPath

yml := `
store:
  book:
    - author: john
      price: 10
    - author: ken
      price: 12
  bicycle:
    color: red
    price: 19.95
`
path, err := yaml.PathString("$.store.book[*].author")
if err != nil {
  //...
}
var authors []string
if err := path.Read(strings.NewReader(yml), &authors); err != nil {
  //...
}
fmt.Println(authors)
// [john ken]

5.1 Print customized error with YAML source code

package main

import (
  "fmt"

  "github.com/goccy/go-yaml"
)

func main() {
  yml := `
a: 1
b: "hello"
`
  var v struct {
    A int
    B string
  }
  if err := yaml.Unmarshal([]byte(yml), &v); err != nil {
    panic(err)
  }
  if v.A != 2 {
    // output error with YAML source
    path, err := yaml.PathString("$.a")
    if err != nil {
      panic(err)
    }
    source, err := path.AnnotateSource([]byte(yml), true)
    if err != nil {
      panic(err)
    }
    fmt.Printf("a value expected 2 but actual %d:\n%s\n", v.A, string(source))
  }
}

output result is the following:

Tools

ycat

print yaml file with color

ycat

Installation

go install github.com/goccy/go-yaml/cmd/ycat@latest

Looking for Sponsors

I'm looking for sponsors this library. This library is being developed as a personal project in my spare time. If you want a quick response or problem resolution when using this library in your project, please register as a sponsor. I will cooperate as much as possible. Of course, this library is developed as an MIT license, so you can use it freely for free.

License

MIT

Owner
Comments
  • Unable to interact with a field where its name containing a dot character

    Unable to interact with a field where its name containing a dot character

    Hi, thank you for your nice library. We are using your lib at our OSS https://github.com/pipe-cd/pipe and it works really nice.

    As the title of this issue, we are facing a problem while parsing the path $.data.envoy-config.yaml because it is containing a dot character. In Kubernetes context, it is normal to specify a field with a file name including its extension so the . will be included. It makes go-yaml parses the path in a wrong way.

    apiVersion: v1
    kind: ConfigMap
    metadata:
      name: envoy
    data:
      envoy-config.yaml: |-
        admin:
          address:
            socket_address:
              address: 0.0.0.0
              port_value: 9095
    

    So do we have any way to deal with this case? Can we use \ to escape the dot or something like that?

    Thank you.

  • Cannot parse yaml file

    Cannot parse yaml file

    My config file cannot be parser. It complains on a unexpected key at 16,1. Removing the empty line before the "masters:" key, makes Unmarshall parse it.

    bad.yml.txt

    The yamlv.2 package parses it correctly, though.

  • Add Marshaler / Unmarshaler interface compatible with encoding/json

    Add Marshaler / Unmarshaler interface compatible with encoding/json

    Supported both interfaces

    Marshaler

    • MarshalYAML() ([]byte, error)
    • MarshalYAML() (interface{}, error)

    Unmarshaler

    • UnmarshalYAML(func(interface{})error) error
    • UnmarshalYAML([]byte) error
  • Unmarshalling a list of maps fails with

    Unmarshalling a list of maps fails with "unexpected key name"

    I got unexpected key name when I tried to unmarshal the following YAML.

    - "min": 1
      "max": 2
    

    Here is the minimum code to reproduce.

    Code

    package main
    
    import (
    	"github.com/goccy/go-yaml"
    	// "gopkg.in/yaml.v3" // No errors when using this
    )
    
    const yamlBody = `
    - "min": 1
      "max": 2
    `
    
    func main() {
    	var v []struct {
    		Min int
    		Max int
    	}
    
    	err := yaml.Unmarshal([]byte(yamlBody), &v)
    	if err != nil {
    		panic(err)
    	}
    }
    

    Go Playground: https://go.dev/play/p/liMbShEkswO

    Outputs

    panic: [2:10] unexpected key name
    >  2 | - "min": 1
       3 |   "max": 2
    

    Tested versions

    • go 1.17, 1.18
    • goccy/go-yaml: 1.9.5
  • scanner: Find quoted token from context

    scanner: Find quoted token from context

    Closes #301

    To resolve an issue with quoted map keys not correctly parsing, this PR changes how it progresses after scanning a quote token.

    The old behaviour was:

    1. scanner reaches a :
    2. pull the characters out of the current scan context buffer and turn it into the map key token
    3. set the previous indent column to the beginning of the buffer So next time it gets to another key in the map, it'll check whether the indent was the same.

    When scanning a quote:

    1. Scan from the beginning to the end of the quote sequence
    2. Add a token, send back to the lexer, and reset the scan context In this scenario, it reaches the :, but nothing is in the scan context buffer because it just went ahead and added the quote token. The previous indent column doesn't get reset, so when it gets to the next map key it thinks the indent increased, which is invalid yaml.

    The new behaviour is essentially to not reset the context after scanning a quote, and when reaching a : check the context tokens, and if it's a quote set the previous indent column to that

  • Multiline block fix

    Multiline block fix

    Introduced the option ForceBlockIfMultiline, which allows multiline strings containing "special YAML characters" to be represented in prettified blocks, instead of being quoted forcefully.

    The main reason for this PR existence is the desire to have more prettified YAML code.

    E.g. let's use the following map element:

    myMap := map[string]interface{}{"v": "# comment\nname: hello\npassword: hello123\nspecial: \":ghost:\"\ntext: |\n  nested multiline!"}
    

    When encoded "normally", the result is:

    v: "# comment\nname: hello\npassword: hello123\nspecial: \":ghost:\"\ntext: |\n  nested multiline!"
    

    When encoded with the ForceBlockIfMultiline option, the result is:

    v: |-
      # comment
      name: hello
      password: hello123
      special: ":ghost:"
      text: |
        nested multiline!
    
  • API to change error behavior

    API to change error behavior

    ドキュメントを読んでたら以下を見たのですが

    errors.ColoredErr = false
    

    yamlパッケージで色々処理を書いているのにerrorsのグローバル変数をいじってエラー表示方法を変えるのがちょっと微妙だなー、と思います。

    1. ユーザー的には errorsがpublicである必要性がない
    2. 必要ならerrorsじゃなくてyamlパッケージに対して処理を依頼するほうがユーザー的には自然
    3. そもそも、エラーを表示する方法を変えるだけなので、yaml側で変更するより、ユーザー側のコードで制御するほうが自然なのでは

    と感じました。

    今のAPIだとこうですが、

    import (
       "github.com/goccy/go-yaml"
       "github.com/goccy/go-yaml/errors" // errors.ColoredErrのためだけに必要
    )
    
    if err := yaml.Unmarshal(...); err != nil {
       errors.ColoredErr = false
       fmt.Println(err)
    }
    

    こんな感じにしてしまえばよいかと

    import (
       "github.com/goccy/go-yaml"
        // go-yaml/errorsは go-yaml/internal/errors に隠蔽してしまう
    )
    
    if err := yaml.Unmarshal(...); err != nil {
       yaml.PrettyPrintError(err) // or yaml.PrettyPrintError(err, boolColoredErr, boolIncludeSource)
    }
    

    とかにするとユーザー側としては

    1. そもそもerrorsパッケージを外部から利用する必要もなければ、internalだから利用もできない
    2. errorsではなくyamlパッケージにPrettyPrintを依頼する形になり自然
    3. 明示的に yaml.PrettyPrintError()を呼ぶことによって、ユーザー側で出力を変更できるし、グローバル変数にも依存しない

    という形にできるかと思います。

    よければPR書きます

  • Comments in YAML break annotated source

    Comments in YAML break annotated source

    Or at least it seems like the comments are causing issue.

    Here's a minimal reproduction:

    package main
    
    import (
    	"fmt"
    
    	"github.com/goccy/go-yaml"
    )
    
    // yamlSrc returns the annotated raw source at pathStr
    func yamlSrc(raw []byte, pathStr string) (msg string, err error) {
    	path, err := yaml.PathString(pathStr)
    	if err != nil {
    		return
    	}
    	source, err := path.AnnotateSource(raw, true)
    	if err != nil {
    		return
    	}
    	msg = "\n" + string(source)
    	return
    }
    
    func main() {
    	src := (`# This is my document
    doc:
      # It has nice inline comments
      inline:
        # And value comments
        - value
        - other value
        # It isn't super consistent
        - last value
      other:
        - value
      # This comment should be line 12
      line:
        # And below should be line 15
        - fifteen
        - sixteen
      done: true  # Line 17
    	`)
    	msg, err := yamlSrc([]byte(src), "$.doc.line[0]")
    	if err != nil {
    		panic(err)
    	}
    	fmt.Println(msg)
    
    	// Output expected (ish):
    	// 13 |     line:
    	// 14 |     # And below should be line 15
    	// 15 |     - fifteen
    	//          ^
    	// 16 |     - sixteen
    	// 17 |   done: true  # Line 17
    	//
    	// Actual output:
    	// 13 |     line:    - fifteen
    	//            ^
    	// 16 |     - sixteen
    	// 17 |   done: true  # Line 17
    	// 18 |
    }
    

    And here's a screenshot of the output on OS X go 1.17 github.com/goccy/go-yaml v1.9.3: image

  • Parsing AST with comments breaks output

    Parsing AST with comments breaks output

    With version v1.8.9 the following program:

    package main
    
    import (
    	"os"
    
    	"github.com/goccy/go-yaml/parser"
    )
    
    func main() {
    	input := []byte(`
    x:
      - a
      #- b
      - c
      #- d
    `)
    	f, err := parser.ParseBytes(input, parser.ParseComments)
    	if err != nil {
    		panic(err)
    	}
    	os.Stdout.Write([]byte(f.String()))
    }
    

    prints the following unexpected output:

    x:
      - a
      - - c
    #- d
    

    I would expect it to print the input unmodified

    x:
      - a
      #- b
      - c
      #- d
    
    
  • Fix to give back error when path not found

    Fix to give back error when path not found

    Fixes https://github.com/goccy/go-yaml/issues/193

    This is happening because Path.Read() assumes it's going to have a non-nil Node if no error returned. But it could give back a nil Node even if no error was given.

    I little poked around the codebase and most of the callers of Path.FilterFile() assume the same does.

    It would be great if you could give me any feedback.

  • explicit-key indicator

    explicit-key indicator "?" is treated as a directive

    https://github.com/goccy/go-yaml/blob/master/scanner/scanner.go#L670

    In all the yaml variants, ? indicates the start of a key in a mapping. In this scanner, ? is treated as a directive.

    YAML 1.1 Example YAML 1.2 Example

    I would fix this, but I don't sufficiently grok the scanner to know how to push it into "the next thing is a mapping key" mode.

  • How to unmarshal a string or a struct value?

    How to unmarshal a string or a struct value?

    For example, take a look at docker-compose file. build can be a string or a struct, and that's perfectly valid. To unmarshal such a situtation, I thought I could try to unmarshal a string before, and then a struct if the former errored out. Unfortunately I found out that TypeError exists, but it's internal:

    https://github.com/goccy/go-yaml/blob/v1.9.8/internal/errors/error.go#L225

    Could you expose it, or suggest me an alternative way to unmarshal a value which may be of two different types?

  •  lost the indentation when use multi lines

    lost the indentation when use multi lines

    releases:
    - name: foo
      chart: ./raw
      values:
      - templates:
        - |
          apiVersion: v1
          kind: ConfigMap
          metadata:
            name: "abc"
            namespace: "abc"
          data:
            foo: FOO
    

    go code:

    func (hs *HelmState) UnmarshalYAML(b []byte) error {
    	decodeVerify := yaml.NewDecoder(b, true)
    	helmStateInfo := make(map[string]interface{})
    	if err := decodeVerify(&helmStateInfo); err != nil {
    		return err
    	}
    	isStrict, err := policy.Checker(helmStateInfo)
    	if err != nil {
    		if isStrict {
    			return err
    		}
    		fmt.Fprintf(os.Stderr, "Warning: %v\n", err)
    	}
    	decodeState := yaml.NewDecoder(b, true)
    
    	return decodeState((*helmStateAlias)(hs))
    }
    
    

    b []byte:

    releases:
    - name: foo
      chart: ./raw
      values:
      - templates:
        - |
          apiVersion: v1
          kind: ConfigMap
          metadata:
          name: "abc"
          namespace: "abc"
          data:
          foo: FOO
    

    Lost the indentation

  • Handling reserved character

    Handling reserved character

    Description

    I found a behavior that I am curious about. Please let me confirm if this is the intended behavior.

    The "@" (x40, at) and "`" (x60, grave accent) are reserved for future use. -- https://yaml.org/spec/1.2.2/

    According to the YAML 1.2.2 specification, "@" is a reserved character, but when using goccy/go-yaml, it seemed to be treated as a non-reserved character. The following is the result of the verification.

    Behavior

    I have checked the behavior of both with the following code.

    package main
    
    import "github.com/goccy/go-yaml" // or "gopkg.in/yaml.v3"
    
    type s struct {
    	Ss []string
    }
    
    var b = []byte(`ss: [@foo, @bar]`)
    
    func main() {
    	var s s
    	if err := yaml.Unmarshal(b, &s); err != nil {
    		panic(err)
    	}
    	for _, o := range s.Ss {
    		println(o)
    	}
    }
    
    

    goccy/go-yaml v1.9.2

    $ go run main.go
    @foo
    @bar
    

    gopkg.in/yaml.v3 v3.0.1

    $ go run main.go
    panic: yaml: found character that cannot start any token
    ...
    
  • yamlのkeyが数値だと文字コードとして読み込まれてしまう

    yamlのkeyが数値だと文字コードとして読み込まれてしまう

    yamlのkeyが引用符で囲まれていない数値で、vmap[string]stringのようにしていると、数値が文字コードとして読み込まれ変換されてしまいます。valueの方は引用符がなくてもそのまま読み込まれるので、バグではないかと思います。 以下再現コードです。

    package main
    
    import (
    	"fmt"
    
    	"github.com/goccy/go-yaml"
    )
    
    func main() {
    	yml := `
    a: a
    98: 98
    `
    	parsed := make(map[string]string)
    	if err := yaml.Unmarshal([]byte(yml), &parsed); err != nil {
    		return
    	}
    	fmt.Print(parsed) // >> map[a:a b:98]
    	yml = `
    a: a
    "98": 98
    `
    	parsed = make(map[string]string)
    	if err := yaml.Unmarshal([]byte(yml), &parsed); err != nil {
    		return
    	}
    	fmt.Print(parsed) // >> map[98:98 a:a]
    }
    
    

    yamlの仕様だったらすみません…

  • There is a bad performance hit when upgrading to >= 1.9.2

    There is a bad performance hit when upgrading to >= 1.9.2

    We found out that after upgrading to 1.9.6 there was a big hit in reading ~~ 270 files. After doing some version comparisions, the problem seems to be introduced in v1.9.3.

    ❯ go get -u github.com/goccy/[email protected]
    go: downgraded github.com/goccy/go-yaml v1.9.3 => v1.8.10
    ❯ go build
    ❯ time ./go-ftw check -d ../coreruleset/tests
    ftw/check: checked 276 files, everything looks good!
    ./go-ftw check -d ../coreruleset/tests  0.50s user 0.09s system 60% cpu 0.961 total
    ❯ go get -u github.com/goccy/[email protected]
    go: upgraded github.com/goccy/go-yaml v1.8.10 => v1.9.3
    ❯ go build
    ❯ time ./go-ftw check -d ../coreruleset/tests
    ftw/check: checked 276 files, everything looks good!
    ./go-ftw check -d ../coreruleset/tests  32.89s user 2.49s system 359% cpu 9.845 total
    ❯ go get -u github.com/goccy/[email protected]
    go: downgraded github.com/goccy/go-yaml v1.9.3 => v1.9.1
    ❯ go build
    ❯ time ./go-ftw check -d ../coreruleset/tests
    ftw/check: checked 276 files, everything looks good!
    ./go-ftw check -d ../coreruleset/tests  0.51s user 0.09s system 64% cpu 0.936 total
    ❯ go get -u github.com/goccy/[email protected]
    go: upgraded github.com/goccy/go-yaml v1.9.1 => v1.9.2
    ❯ time ./go-ftw check -d ../coreruleset/tests
    ftw/check: checked 276 files, everything looks good!
    ./go-ftw check -d ../coreruleset/tests  0.52s user 0.09s system 104% cpu 0.581 total
    ❯ go get -u github.com/goccy/[email protected]
    go: upgraded github.com/goccy/go-yaml v1.9.2 => v1.9.3
    ❯ go build
    ❯ time ./go-ftw check -d ../coreruleset/tests
    ftw/check: checked 276 files, everything looks good!
    ./go-ftw check -d ../coreruleset/tests  32.47s user 2.41s system 358% cpu 9.724 total
    

    See https://github.com/coreruleset/go-ftw/issues/115. Right now we downgraded to pre 1.9.3, but probably we want to check out what the problem is and write some benchmarks.

  • go-yaml does not properly set indent for nodes obtained from in-line JSON

    go-yaml does not properly set indent for nodes obtained from in-line JSON

    The following program shows that nodes derived from in-line JSON do not properly set their indent, resulting in corrupted output.

    https://play.golang.com/p/jxYRN0uVB9J

    This returns the following output:

    processors:
      - date:
          if: "ctx.event?.timezone == null && ctx._temp_?.raw_date != null"
          target_field: "@timestamp"
          on_failure:
        ppend":
        eld": "error.message", "value": "{{{ _ingest.on_failure_message }}}"}}]
    

    Note that the data is correctly deserialised as can be seen when the data is passed through an any and re-serialised, https://play.golang.com/p/6cCkHpw2MYr.

Go-yaml - Yaml parsing Toolkit For Golang

go-yaml 介绍 gopkg.in/yaml.v3 已经是个非常好用的包,但是在实际开发中总有类型转换带来的麻烦,go-yaml只是在它的基础上,简单的一层

Jan 13, 2022
Light weight, extensible configuration management library for Go. Built in support for JSON, TOML, YAML, env, command line, file, S3 etc. Alternative to viper.
Light weight, extensible configuration management library for Go. Built in support for JSON, TOML, YAML, env, command line, file, S3 etc. Alternative to viper.

koanf (pronounced conf; a play on the Japanese Koan) is a library for reading configuration from different sources in different formats in Go applicat

Jan 8, 2023
Golang Configuration tool that support YAML, JSON, TOML, Shell Environment

Configor Golang Configuration tool that support YAML, JSON, TOML, Shell Environment (Supports Go 1.10+) Usage package main import ( "fmt" "github.c

Dec 29, 2022
Generic templating tool with support of JSON, YAML and TOML data

gotempl Small binary used to generate files from Go Templates and data files. The following formats are supported: JSON YAML TOML Usage usage: gotempl

Jun 15, 2022
JSON or YAML configuration wrapper with convenient access methods.

Config Package config provides convenient access methods to configuration stored as JSON or YAML. This is a fork of the original version. This version

Dec 16, 2022
Library providing routines to merge and validate JSON, YAML and/or TOML files
Library providing routines to merge and validate JSON, YAML and/or TOML files

CONFLATE Library providing routines to merge and validate JSON, YAML, TOML files and/or structs (godoc) Typical use case: Make your application config

Sep 26, 2022
A better way to marshal and unmarshal YAML in Golang

YAML marshaling and unmarshaling support for Go Introduction A wrapper around go-yaml designed to enable a better way of handling YAML when marshaling

Jan 4, 2023
create a bootable disk image from Docker image or a yaml config

docker2boot docker2boot creates a bootable disk from either a Docker image or a config yaml file Features status dns Y cloud-init Y network Y ssh TODO

Oct 30, 2022
It syncronizes the configuration described in a YAML file against your GitHub Organization

It syncronizes the configuration described in a YAML file against your GitHub Organization. Combined with a CI system, it can be used to implement GitOps for GitHub.

Jul 19, 2021
Golang library for reading properties from configuration files in JSON and YAML format or from environment variables.

go-config Golang library for reading properties from configuration files in JSON and YAML format or from environment variables. Usage Create config in

Aug 22, 2022
Golang config.yaml loader

Description goconfig is a configuration library designed using the following pri

May 31, 2022
Tmpl - A tool to apply variables from cli, env, JSON/TOML/YAML files to templates

tmpl allows to apply variables from JSON/TOML/YAML files, environment variables or CLI arguments to template files using Golang text/template and functions from the Sprig project.

Nov 14, 2022
SmartYAML - Go package to handle YAML

SmartYAML - Go package to handle YAML The smartyaml is a go package to handle parsed YAML files more confortable. This package is not a parser, it use

Feb 25, 2022
VINYL Inscribes Nettlesome YAML Legibly

VINYL Inscribes Nettlesome YAML Legibly VINYL formats yaml files into a canonical format retaining comments and setting the indentation by default to

Jan 18, 2022
Go-config - Config parser for go that supports environment vars and multiple yaml files

go-multiconfig This package is able to parse yaml config files. It supports gett

Jun 23, 2022
HCL is the HashiCorp configuration language.

HCL HCL is a toolkit for creating structured configuration languages that are both human- and machine-friendly, for use with command-line tools. Altho

Jan 9, 2023
Go library for the TOML language

go-toml Go library for the TOML format. This library supports TOML version v1.0.0-rc.3 Features Go-toml provides the following features for using data

Dec 27, 2022
Tom's Obvious, Minimal Language

TOML Tom's Obvious, Minimal Language. By Tom Preston-Werner, Pradyun Gedam, et al. This repository contains the in-development version of the TOML spe

Jan 2, 2023