Tom's Obvious, Minimal Language

Related tags

Configuration toml
Overview

TOML logo

TOML

Tom's Obvious, Minimal Language.

By Tom Preston-Werner, Pradyun Gedam, et al.

This repository contains the in-development version of the TOML specification. You can find the released versions at https://toml.io.

Objectives

TOML aims to be a minimal configuration file format that's easy to read due to obvious semantics. TOML is designed to map unambiguously to a hash table. TOML should be easy to parse into data structures in a wide variety of languages.

Example

# This is a TOML document.

title = "TOML Example"

[owner]
name = "Tom Preston-Werner"
dob = 1979-05-27T07:32:00-08:00 # First class dates

[database]
server = "192.168.1.1"
ports = [ 8000, 8001, 8002 ]
connection_max = 5000
enabled = true

[servers]

  # Indentation (tabs and/or spaces) is allowed but not required
  [servers.alpha]
  ip = "10.0.0.1"
  dc = "eqdc10"

  [servers.beta]
  ip = "10.0.0.2"
  dc = "eqdc10"

[clients]
data = [ ["gamma", "delta"], [1, 2] ]

# Line breaks are OK when inside arrays
hosts = [
  "alpha",
  "omega"
]

Comparison with Other Formats

TOML shares traits with other file formats used for application configuration and data serialization, such as YAML and JSON. TOML and JSON both are simple and use ubiquitous data types, making them easy to code for or parse with machines. TOML and YAML both emphasize human readability features, like comments that make it easier to understand the purpose of a given line. TOML differs in combining these, allowing comments (unlike JSON) but preserving simplicity (unlike YAML).

Because TOML is explicitly intended as a configuration file format, parsing it is easy, but it is not intended for serializing arbitrary data structures. TOML always has a hash table at the top level of the file, which can easily have data nested inside its keys, but it doesn't permit top-level arrays or floats, so it cannot directly serialize some data. There is also no standard identifying the start or end of a TOML file, which can complicate sending it through a stream. These details must be negotiated on the application layer.

INI files are frequently compared to TOML for their similarities in syntax and use as configuration files. However, there is no standardized format for INI and they do not gracefully handle more than one or two levels of nesting.

Further reading:

Get Involved

Documentation, bug reports, pull requests, and all other contributions are welcome!

Wiki

We have an Official TOML Wiki that catalogs the following:

  • Projects using TOML
  • Implementations
  • Validators
  • Language-agnostic test suite for TOML decoders and encoders
  • Editor support
  • Encoders
  • Converters

Please take a look if you'd like to view or add to that list. Thanks for being a part of the TOML community!

Issues
  • Proposal: Reference shortcut for nesting tables

    Proposal: Reference shortcut for nesting tables

    Consider the following exampe:

    [servers]
     
      [servers.alpha]
      ip = "10.0.0.1"
      dc = "eqdc10"
       
      [servers.beta]
      ip = "10.0.0.2"
      dc = "eqdc10"
    

    Idea: add a shortcut character to reference the outer table.

    Example:

    [servers]
     
      [#.alpha]
      ip = "10.0.0.1"
      dc = "eqdc10"
       
      [#.beta]
      ip = "10.0.0.2"
      dc = "eqdc10"
    

    The character # is illustrative and may have to be reconsidered giving it's used already for comments.

    The proposal also considers multiple levels:

    [servers]
     
      [#.alpha]
      ip = "10.0.0.1"
      dc = "eqdc10"
    
    [#.#.firewall]
    inbound = "0.0.0.0/24" # this would become `servers.alpha.firewall.inbound`
    outbound = "0.0.0.0/24" # similarly, `servers.alpha.firewall.outbount`
    
      [#.beta]
      ip = "10.0.0.2"
      dc = "eqdc10"
    

    The multi-level indicator, e.g. #.#.#..., must match the current structure. For example, #.#.#.#.foo right below a single-level table [bar] must be considered invalid. IDEs and plugins for text editors should be able to provide tooltip to indicate the expanded name of the referenced tables, expanding the value.

    The benefit of this feature is to simplify typing while keeping explicitly defined the level of the table, and also in reducing the chances of typos when nesting tables. Can also facilitate when copying/pasting snippets.

    new-syntax 
    opened by brunoborges 92
  • Allow keys in key-value pairs to be paths

    Allow keys in key-value pairs to be paths

    The only remaining idea from #292 that has not been decided upon and does not have a dedicated issue.

    I mean, I don't know how much I like it myself but, hey, this needs discussion so, here's a dedicated issue for it.

    [document]
    title = "Hello!"
    meta.charset = "utf-8"
    
    new-syntax 
    opened by pradyunsg 86
  • Adds multi-line string to spec.

    Adds multi-line string to spec.

    I think there should be some kind of baked-in support for multi-line strings, especially since that's the primary reason (IMO) that JSON sucks as a specification language. Here I'm adding the CoffeeScript style triple-quotes but I'm fine with anything, really.

    opened by mbleigh 75
  • Revisit array of table syntax

    Revisit array of table syntax

    I found the type "array of table" not especially easy to grasp in TOML. This is because the syntax of an array of table is different from an array of, say, integer. It is not the case in JSON. So while I found TOML clearer than JSON regarding table, I found JSON easier to understand regarding array of table.

    In the end, I was wondering if the type "array of table" was absolutely necessary in a config file. My point is that the way the data are stored (table of table vs. array of table) might be of low interest for the end-user that just want to modify some parameters.

    I understand that, compared to "table of table", "array of table" has:

    • ordered elements
    • unnamed elements.

    Among actual TOML usage, is there a situation where "array of table" is much more efficient than "table of table" ?

    To be a little more specific, here are the comparison of both syntax (not exactly similar of course): Array of table:

    [[products]]
        name = "Hammer"
        sku = 738594937
    
    [[products]]
    
    [[products]]
        name = "Nail"
        sku = 284758393
    

    Table of table:

    
    [product.hammer]
        name = "Hammer"
        sku = 738594937
    
    [product.empty]
    
    [products.Nail]
        name = "Nail"
        sku = 284758393
        color = "gray"
    

    IMO, the advantage of using table of table only are:

    • a unique syntax (less confusing)
    • each table has a name (less need of referring to the manual)

    My question is certainly not if it is relevant to remove the array of table from the specs, but to see if a best practice could encourage to avoid array of table against table of table.

    new-syntax 
    opened by maxhaz 71
  • range type

    range type

    I'm new to TOML and really liking it. The one thing I'd really find helpful is a range type, which implementations could interpret either as a range object (e.g., Python) or as an explicit array, depending on the language. I anticipate "just use a 3-array" or "just provide start, stop, and step attributes" as responses, but if you search you'll find that YAML and JSON users also request ranges from time to time. So I think there is a desirable feature here. I'm not going to suggest syntax but array syntax without commas [0 10 1] or doubled periods 0..10..1 or even Mathematica span style 0;;10;;1 pop into mind.

    new-syntax 
    opened by alan-isaac 67
  • Support single-quoted strings to avoid double \

    Support single-quoted strings to avoid double \

    The example for TOML shows how bad it gets when writing a Windows path that has , unfortunately some things that get configured need to let a user enter a regular expression. Regular expressions are filled with back-slashes, and adding the extra backslash constantly is very painful.

    To give TOML a fighting chance when someone might need to use a few backslashes in a config file, I propose using single quotes to designate a raw string, ie:

    somevar = 'this is a \d+ \w+ type of string'
    

    This would retain the existing double-quote rules to avoid breaking existing usage.

    opened by bbangert 64
  • Allow

    Allow "[]" to return to global scope (for adding sibling array after a table)

    I'm trying to model this Rust struct in TOML:

    #[derive(Debug, Clone, PartialEq, Deserialize)]
    pub struct WhitelistConfig<T: DeviceIdentifier> {
        appliance: Appliance,
        rules: Vec<Rule>,
        
        #[serde(default)]
        ignore: PhantomData<T>
    }
    

    When writing it out in TOML, I believe the natural way to read/write it would be:

    1. Provide information about the appliance this config file connects to
    2. Provide the list of rules (which could be long)

    That would look something like...

    [appliance]
    host = "teddriggs-dev"
    api_key = "MY-API-KEY"
    
    # this isn't valid right now; it will consider the field to be part of `appliance`
    rules = [
        { tag = "whitelist" },
        { group_id = 1 }
    ]
    

    One approach I thought of that could address this would be allowing [] to appear once to return to global scope after entering a table. It would be invalid to use [] if the document started with key-value pairs, avoiding the splitting of a table definition.

    This might be too narrow a case, but I think the pattern of 'metadata + a list' seems likely to occur somewhat frequently. This may also dovetail with #309; shorter syntax for arrays-of-tables would make me less concerned about teaching users the [[rules]] construct.

    opened by TedDriggs 52
  • Tuples and Inline Tables: A Motivation

    Tuples and Inline Tables: A Motivation

    This builds on https://github.com/toml-lang/toml/pull/154, which would be very useful regardless of whether this proposal is accepted.

    Hurray for tuples! @mojombo

    Currently, there is no syntax for inline tables, which means that you're forced to create a new section for simple cases. In Cargo:

    [dependencies.hammer]
    
    version = "1.0.0"
    git = "https://github.com/wycats/hammer.rs"
    

    We have a shorthand for the case where a dependency only needs to specify a version:

    [dependencies]
    
    hammer = "1.0.0"
    

    With tuples, we could do something like:

    [dependencies]
    
    hammer = ("1.0.0", "git", "https://github.com/wycats/hammer.rs")
    

    I would like to propose a syntax for inline tables:

    [dependencies]
    
    hammer = ("1.0.0", git: "https://github.com/wycats/hammer.rs")
    # or alternately
    hammer = ("1.0.0", git = "https://github.com/wycats/hammer.rs")
    

    I would be comfortable with restricting inline tables to the last element of a tuple, to eliminate the need for additional braces or something around the table.

    opened by wycats 51
  • Add inline table syntax.

    Add inline table syntax.

    Concrete proposal for the inline table syntax I first proposed in Issue #219. Here's a quick taste:

    # They should look familiar and obvious
    name = { first = "Tom", last = "Preston-Werner" }
    point = { x = 1, y = 2 }
    
    # They make tuples unnecessary by allowing mixed types (they are just tables, after all).
    # Unlike tuples, they are self-documenting via the key names.
    address = { proto = "http", ip = "10.0.0.1", port = 8080 }
    
    # Arrays of tables with less hassle
    points = [ { x = 1, y = 2, z = 3 },
               { x = 7, y = 8, z = 9 },
               { x = 2, y = 4, z = 8 } ]
    

    This is about as brief as I could think to make it, so if there are specific issues that need clarifying, please bring them up.

    opened by mojombo 49
  • The spec language seems to forbid writing to the same defined table using dotted keys

    The spec language seems to forbid writing to the same defined table using dotted keys

    (I may have made some mistakes in this write-up, but I hope I have made the contradiction obvious by the time you get to the end. Please read to the end, because I may be identifying multiple problems, so if you feel I am wrong about one issue you should still consider the rest of this write-up.)

    Let's start here:

    Dotted keys define everything to the left of each dot as a table. Since tables cannot be defined more than once, redefining such tables using a [table] header is not allowed. Likewise, using dotted keys to redefine tables already defined in [table] form is not allowed.

    The contradiction is here:

    1. Dotted keys define everything to the left of each dot as a table.
    2. tables cannot be defined more than once

    Here, "define" must mean explicitly defined (because tables can be implicitly defined multiple times by either dotted keys or headers) and no delineation is made between tables "defined in dotted keys" versus tables defined in headers (referred to elsewhere in the spec as "directly defined"). It is stated that any table (explicitly) "defined" cannot be (explicitly) "defined" again. That means this should be invalid:

    [fruit]
    apple.color = "red" # Here, apple is "defined as a table"
    apple.taste.sweet = true # Here apple is "defined" AGAIN as a table
    

    I would also add that the spec should explicitly state that "dotted keys" can NOT refer to keys separated by dots inside headers. Otherwise, that would also mean that defining headers out of order would be invalid.

    [fruit.apple]
    # `fruit` is implicitly defined as a table
    # `apple` is explicitly defined as a table within `fruit`
    
    [fruit]
    # fruit is explicitly defined as a table
    
    # of course, this document should be valid!
    

    Now, if you interpret "define" as implicitly defined in this case, that still doesn't work. More on this later.

    We see the following elsewhere in the spec:

    As long as a key hasn't been directly defined, you may still write to it and to names within it.

    # This makes the key "fruit" into a table.
    fruit.apple.smooth = true
    
    # So then you can add to the table "fruit" like so:
    fruit.orange = 2
    

    The above is the only place in the spec where the term "directly defined" is used to delineate between the different kinds of "define". (Aside from where it says that in-line tables are "fully defined" at their location and cannot be added to or modified, but that is pretty air-tight so I don't want to focus on it at all.)

    The (first) paragraph in question is followed by "The [table] form can, however, be used to define sub-tables within tables defined via dotted keys." I don't appreciate how the first two examples follow naturally from the principle "Since tables cannot be defined more than once" but the third example is a contradiction of the principle. It's fine for all three of these examples to be fine in TOML, but not without delineating between the different kinds of "define".

    The contradiction leads me to question whether the following is an example of a valid contradiction of the aforementioned principle:

    Is it valid for "dotted keys" (not in headers) to modify something implicitly defined as a table in a header? My guess is yes, since if you change the order it is valid.

    [fruit.apple.taste]
    # `fruit` is implicitly defined as a table
    # `apple` is implicitly defined as a table in `fruit`
    # `taste` is explicitly defined as a table in `apple`
    [fruit]
    # fruit is explicitly defined as a table
    apple.color = "red"
    # apple is (indirectly) defined as a table with color set to "red"
    

    While there are occurrences in the spec where you can easily infer the difference between the kinds of "define" being used (including in some examples above), the top quotation seems to imply it is possible to possible to implement the "dotted keys" by only delineating between defined tables and implicitly defined tables (leaving aside arrays and in-line tables for now), when in fact, it is not possible. You HAVE TO delineate between dotted key definitions (not in headers) versus header definitions. There is no way to satisfy all the rules any other way.


    Here is an example of an implementation. It's a bit TypeScripty, hopefully others can understand what I am getting at.

    Define enum ScopeType as having members: { Inferred, Defined } Define scopeTypes as a Map/Hash of Table -> ScopeType. Let global be the global scope

    A Map pairs keys with values, and has methods "has", "get" and "set". "has" returns whether a mapping exists for a given key. "get" returns what a given key maps to. "set" maps a given key to a given value. In this case, ScopeTypes.has(value) is another way of expressing that a given value is not a literally defined value, e.g.1 or false
    [a]
    # assert global["a"] == undefined or scopeTypes.get(global["a"]) == ScopeType::Inferred
    # define `a` as global["a"] or an empty table {}
    # scopeTypes.set(a, ScopeType::Defined)
    
    b.c = 1
    # assert a["b"] == undefined or scopeTypes.has(a["b"])
    # scopeTypes.set(b, ScopeType::Inferred)
    
    [a.b] # should be forbidden
    # assert global["a"] == undefined or scopeTypes.has(global["a"])
    # define `a` as global["a"] or an empty table {}
    # scopeTypes.set(a, ScopeType::Inferred)
    
    # assert a["b"] == undefined or scopeTypes.get(a["b"]) == ScopeType::Inferred
    # define `b` as a["b"] or an empty table {}
    # scopeTypes.set(b, ScopeType::Defined)
    

    The crux of the problem here is in our [a.b] logic, where b may only be Inferred, in order to allow these cases:

    [a.b.c]
    [a.b]
    # `a` is Inferred
    # `b` was Inferred, but is now Defined
    
    [a]
    [a.b] # `a` is Defined
    # `b` was undefined, is now Defined
    

    And block this case:

    [a.b]
    # b is defined
    [a.b]
    # b is defined already! error!
    

    Hence, there is no way to block "redefining such tables [tables defined by dotted keys] using a [table] header is not allowed." E.g.

    [a]
    b.c = 1
    [a.b] # forbidden?
    # `a` is Inferred
    # b is must be Defined in order to block this
    

    So let's rewrite our logic where we set b in b.c = 1 to be Defined in order to account for the above case:

    a.b = 1
    # assert global["a"] == undefined or scopeTypes.get(global["a"]) == Defined
    # define `a` as global["a"] or empty table {}
    # scopeTypes.set(a, ScopeType::Defined)
    # set a["b"] = 1
    

    Now we can't block this:

    [fruit.apple]
    # fruit is Inferred
    # apple is Defined
    
    [fruit]
    # fruit is Defined
    
    apple.color = "red" # This is acceptable by the above logic
    
    # To block this, we'd need to assert `apple` is not Defined
    

    There is no way to block the above document without blocking the use of the same dotted-key-defined-table using only 2 ScopeType enums.

    a.b = 1
    # `a` is Defined here
    
    a.c = 2
    # We must allow `a` to be Defined for this
    # But if we allow `a` to be Defined, we can't block the previous case!
    

    I am trying to get the point across using code here because I don't know of a better way to express this technically. We need to delineate between dotted key define's versus header define's in the spec in order for it to make logical sense.

    (I may have made some mistakes in this write-up, but I hope I have made the contradiction obvious by the time you've managed to read this far.)

    clarification 
    opened by Validark 47
  • Datetime literals are not appropriate for a minimal language

    Datetime literals are not appropriate for a minimal language

    If this is to be taken at face value: "TOML aims to be a minimal configuration file format", then embedding all of RFC 3339 to get datetime literals makes no sense. Since the string values of TOML keys are restricted, I don't see TOML as being appropriate as a general data serialization protocol (in which a native datetime literal would be useful), so I assume it really is meant to be for human-edited config files. I've written/edited plenty of configuration files, and I can't remember when I ever needed to encode a datetime by hand.

    opened by thezerobit 46
  • Clarification: Table section editing inline table in inline array

    Clarification: Table section editing inline table in inline array

    The spec says:

    Any reference to an array of tables points to the most recently defined table element of the array.

    which means that this is currently valid (verified at http://toml-online-parser.ovonick.com/):

    a = [{ b = 1 }]
    [a.c]
    foo = 1
    
    {
        "a": [
            {
                "b": {"type" : "integer", "value" : "1"},
                "c": {
                    "foo": {"type" : "integer", "value" : "1"}
                }
            }
        ]
    }
    

    which seems a bit inconsistent since extending inline tables in general is invalid:

    a = { b = 1 }
    [a.c]
    foo = 1
    

    Is this intentional?

    opened by brandonchinn178 6
  • Lack of Offset Time

    Lack of Offset Time

    Was wondering why TOML does not support the combination of a Local Time + Offset? Does it not make semantic sense, or is there another reason for excluding it?

    opened by linclelinkpart5 2
  • Proposal: a single universal separation method for inline tables, arrays, and more

    Proposal: a single universal separation method for inline tables, arrays, and more

    My attitudes towards the use of newlines and commas within inline tables and in general have softened considerably since #525. Since nesting is trending in a JSON-like manner, allow me to propose a bound on the other extreme. How about a single universal standard for separating anything in different parts of the document?

    Currently

    Here is how we separate items within TOML. Note that all three separation methods are intentionally different.

    • Between table and array-of-table headers, we separate key/value pairs (or "KVPs") with newlines (and optional comments), with surrounding whitespace characters. in the ABNF, this is called ws-comment-newline.
    • Within an inline table, we separate KVPs with commas and whitespace only. Trailing commas aren't allowed. (And the way things are trending, this will change, but I digress.)
    • Within an array, we separate values with ws-comment-newline, with a single comma permitted between or after values. Newlines (with optional comments) are not sufficient. The comma must exist between each pair of values, and an optional comma may exist after the last value.

    Proposed

    For any of the three separation scenarios described above, let's allow the following as separators:

    1. At the beginning of one of these regions, we will only allow ws-comment-newline. That is, we will permit whitespace (space and tab) and newlines (with newlines preceded with optional comments) before the first item, and nothing else.
    2. Between items, we will allow ws-comment-newline, so long as one comma (not in a comment) or one newline is present.
    3. After the last item, we will allow ws-comment-newline, with an optional comma (not in a comment) permitted.
    4. The between-item separators can have a mixture of commas and newlines, and there is no requirement that they must all be consistent.

    That's it. This is backwards compatible with current separation formats.

    Newly Permitted

    How would this standard extend the separators currently used?

    • Inline tables could span multiple lines. A comma is optional if there's a newline in the separator. And an optional trailing comma would be allowed.
    • Array values could be separated with newlines only. Commas wouldn't be required in this case.
    • Most radically, we could separate KVPs outside of inline tables with just commas and whitespace on lines, allowing the same syntax in table sections that are allowed in inline tables.

    This is admittedly very broad, but it is more permissive than what #516 and #525 allow.

    I can write up examples of what would newly be permitted, later in the day.

    What are your thoughts?

    opened by eksortso 9
  • Assigning values via an array-of-tables like syntax

    Assigning values via an array-of-tables like syntax

    [^gap]: # long gap contains relevant configuration for each preceding

    if i have 3 objects i can define them like this

    [[long.path.to.array]]
    value = 1
    # long space defining stuff for preceding
    [[long.path.to.array]]
    value = 2
    # long space defining stuff for preceding
    [[long.path.to.array]]
    value = 3
    # long space defining stuff for preceding
    

    which is good

    also works well if the short thing works if long.path.to.array is a table

    long.path.to.table.1 = 1
    # long space defining stuff for preceding
    long.path.to.table.2 = 2
    # long space defining stuff for preceding
    [long.path.to.table.3]
    sometimes = 1
    config = 2
    is = 3
    big = 4
    # long space defining stuff for preceding
    

    but if the thing i want to store is

    long.path.to.array = [1, 2, { sometimes = 1, config = 2, is = 3, big = 4}]
    

    their is no equivalent.

    proposal is to support

    [long.path.to.array]=1
    # long gap
    [long.path.to.array]=2
    # long gap
    [[long.path.to.array]]
    sometimes = 1
    config = 2
    is = 3
    big = 4
    # long gap
    

    this make mixed arrays a huge pain in for a lot of the configs I write at work, spacing out the assignment is important for readability's sake and just for symetry and alt would be support assigning to empty

    [[long.path.to.array]]
    =1
    # long space defining stuff for preceding
    [[long.path.to.array]]
    =2
    # long space defining stuff for preceding
    [[long.path.to.array]]
    sometimes = 1
    config = 2
    is = 3
    big = 4
    # long space defining stuff for preceding
    

    allowing assigment to empty is good becuse it means i can translate more json to toml right now no way to support the json document

    "hello world"
    
    opened by lizelive 2
Releases(1.0.0)
  • 1.0.0(Jan 12, 2021)

    About time TOML hit 1.0.0!

    • Clarify how tables are created and defined.
    • Clarify and describe the top-level table.
    • Clarify that indentation before keys is ignored.
    • Clarify that indentation before table headers is ignored.
    • Clarify that indentation between array values is ignored.
    Source code(tar.gz)
    Source code(zip)
  • 1.0.0-rc.3(Oct 7, 2020)

    • Clarify that comments and newlines are allowed before commas in arrays.
    • Mark the ABNF as canonical, and reference it from the text specification.
    Source code(tar.gz)
    Source code(zip)
  • 1.0.0-rc.2(Aug 9, 2020)

    • Create https://toml.io as the new primary location to read the TOML spec.
    • Clarify meaning of "quotation marks".
    • Clarify meaning of "expected" value ranges.
    • Clarify that EOF is allowed after key/value pair.
    • Clarify that the various styles for writing keys are equivalent.
    • Clarify that line-ending backslashes must be unescaped in multi-line strings.
    • Add examples for invalid float values.
    Source code(tar.gz)
    Source code(zip)
  • v1.0.0-rc.1(Apr 3, 2020)

    • Clarify in ABNF how quotes in multi-line basic and multi-line literal strings are allowed to be used.
    • Leading zeroes in exponent parts of floats are permitted.
    • Clarify that control characters are not permitted in comments.
    • Clarify behavior of tables defined implicitly by dotted keys.
    • Clarify that inline tables are immutable.
    • Clarify that trailing commas are not allowed in inline tables.
    • Clarify in ABNF that UTF-16 surrogate code points (U+D800 - U+DFFF) are not allowed in strings or comments.
    • Allow raw tab characters in basic strings and multi-line basic strings.
    • Allow heterogenous values in arrays.
    Source code(tar.gz)
    Source code(zip)
  • v0.5.0(Jul 10, 2018)

    • Add dotted keys.
    • Add hex, octal, and binary integer formats.
    • Add special float values (inf, nan)
    • Rename Datetime to Offset Date-Time.
    • Add Local Date-Time.
    • Add Local Date.
    • Add Local Time.
    • Add ABNF specification.
    • Allow space (instead of T) to separate date and time in Date-Time.
    • Allow accidental whitespace between backslash and newline in the line continuation operator in multi-line basic strings.
    • Specify that the standard file extension is .toml.
    • Specify that MIME type is application/toml
    • Clarify that U+007F is an escape character.
    • Clarify that keys are always strings.
    • Clarify that you cannot use array-of-table to append to a static array.
    • Clarify that a TOML file must be a valid UTF-8 document.
    • Clarify valid Array values.
    • Clarify that literal strings can be table keys.
    • Clarify that at least millisecond precision expected for Date-Time and Time.
    • Clarify that comments are OK in multiline arrays.
    • Clarify that +0, -0, +0.0, and -0.0 are valid and what they mean.
    • TOML has a logo!
    Source code(tar.gz)
    Source code(zip)
  • v0.4.0(Feb 12, 2015)

    • Add Inline Table syntax.
    • Allow underscores in numbers.
    • Remove forward slash as an escapable character.
    • Unicode escapes must be scalar values.
    • Newline is now defined as LF or CRLF.
    Source code(tar.gz)
    Source code(zip)
  • v0.3.0(Nov 10, 2014)

    • Add scientific notation for floats.
    • Allow optional + prefix on integers.
    • Switch to RFC 3339 for datetimes (allowing offsets and fractional seconds).
    • Add multiline and literal strings.
    • Clarify what characters valid keys can contain.
    Source code(tar.gz)
    Source code(zip)
  • v0.2.0(Sep 24, 2013)

  • v0.1.0(Mar 17, 2013)

Owner
TOML
Tom's Obvious, Minimal Language (and friends)
TOML
YAML support for the Go language.

YAML support for the Go language Introduction The yaml package enables Go programs to comfortably encode and decode YAML values. It was developed with

null 5.8k Jul 3, 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

HashiCorp 4.1k Jul 4, 2022
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

Thomas Pelletier 1.3k Jun 29, 2022
Graph-based Declarative Configuration Language

Virgo Configuration Language Most configuration problems reduce to graphs, e.g. Dockerfiles and Makefiles But there are no graph-based configuration l

Matt Rickard 108 Jun 15, 2022
YAML support for the Go language

YAML support for the Go language

Masaaki Goshima 719 Jun 25, 2022
⛳ A minimal programming language inspired by Ink, JavaScript, and Python.

⛳ Golfcart My blog post: Creating the Golfcart Programming Language Getting Started Scope Rules Usage Building and tests Contributions License Golfcar

Andrew Healey 26 Feb 23, 2022
Gec is a minimal stack-based programming language

Gec is a minimal stack-based programming language

aiocat 1 May 22, 2022
Gopherscript is a secure and minimal scripting language written in Go.

Gopherscript Gopherscript is a secure scripting/configuration language written in Go. It features a fined-grain permission system and enforces a stron

Debloat 17 Jun 15, 2022
A minimal framework to build web apps; with handler chaining, middleware support; and most of all standard library compliant HTTP handlers(i.e. http.HandlerFunc).

WebGo v4.1.3 WebGo is a minimalistic framework for Go to build web applications (server side) with zero 3rd party dependencies. Unlike full-fledged fr

Kamaleshwar 247 Jun 15, 2022
Minimal and Beautiful Go testing framework

Goblin A Mocha like BDD testing framework written in Go that requires no additional dependencies. Requires no extensive documentation nor complicated

null 852 Jun 26, 2022
Minimal cgo bindings for libenca

enca This is a minimal cgo bindings for libenca. If you need to detect the language of a string you can use guesslanguage package. Supported Go versio

Nikita Vershinin 11 Jan 24, 2022
Minict is a minimal container runtime written in Go.

Minict Minict is a minimal container runtime written in Go. It was made mainly for learning purposes and is intended to be as simple as possible.

null 149 May 11, 2022
Minimal UART client in Golang that dumps LPC1343 chips that are locked at CRP1.

Howdy y'all, This is a quick and dirty client for the UART bootloader of the LPC1343, and probably other bootloaders in that chip family. This client

Travis Goodspeed 13 Mar 30, 2022
Minimal and idiomatic WebSocket library for Go

websocket websocket is a minimal and idiomatic WebSocket library for Go. Install go get nhooyr.io/websocket Highlights Minimal and idiomatic API First

Anmol Sethi 2.3k Jun 24, 2022
Minimal structured logging library for Go

slog slog is a minimal structured logging library for Go. Install go get cdr.dev/slog Features Minimal API First class context.Context support First c

Coder 243 Jun 19, 2022
Minimal and idiomatic WebSocket library for Go

websocket websocket is a minimal and idiomatic WebSocket library for Go. Install go get nhooyr.io/websocket Highlights Minimal and idiomatic API First

Anmol Sethi 2.3k Jun 24, 2022
❄️ Elsa is a minimal, fast and secure runtime for JavaScript and TypeScript written in Go

Elsa Elsa is a minimal, fast and secure runtime for JavaScript and TypeScript written in Go, leveraging the power from QuickJS. Features URL based imp

Elsa 2.6k Jun 23, 2022
Minimal HTTP File Server for pentesting written in Go

Golang implementation of simple HTTP server with upload feature.

Vincent Carlos 76 May 11, 2022
Super minimal, rock-solid foundation for concurrent GUI in Go.

faiface/gui Super minimal, rock-solid foundation for concurrent GUI in Go. Installation go get -u github.com/faiface/gui Currently uses GLFW under th

Michal Štrba 444 Jun 23, 2022
A minimal and extensible structured logger

⚠️ PRE-RELEASE ⚠️ DO NOT IMPORT THIS MODULE YOUR PROJECT WILL BREAK package log package log provides a minimal interface for structured logging in ser

Go kit 104 Jun 29, 2022
Shelby is a fast ⚡️ , lightweight ☁️ , minimal✨, shell prompt written in Go.

Shelby is a fast ⚡️ ,lightweight ☁️ ,minimal ✨ , shell prompt written in Pure Go. Installation Follow the steps below(Linux and macOS), and Post Insta

Athul Cyriac Ajay 164 Apr 24, 2022
Dear ImGui: Bloat-free Graphical User interface for C++ with minimal dependencies

Dear ImGui (This library is available under a free and permissive license, but needs financial support to sustain its continued improvements. In addit

omar 39.4k Jul 1, 2022
Package mafsa implements Minimal Acyclic Finite State Automata in Go, essentially a high-speed, memory-efficient, Unicode-friendly set of strings.

MA-FSA for Go Package mafsa implements Minimal Acyclic Finite State Automata (MA-FSA) with Minimal Perfect Hashing (MPH). Basically, it's a set of str

SmartyStreets (Archives) 290 Jun 22, 2022
Grafana Tempo is a high volume, minimal dependency distributed tracing backend.

Grafana Tempo is an open source, easy-to-use and high-scale distributed tracing backend. Tempo is cost-efficient, requiring only object storage to ope

Grafana Labs 2.1k Jun 23, 2022
A minimal filecoin client library

filclient A standalone client library for interacting with the filecoin storage network Features Make storage deals with miners Query storage ask pric

Application Research Group 31 Jun 22, 2022
Kubedock is a minimal implementation of the docker api that will orchestrate containers on a Kubernetes cluster, rather than running containers locally.

Kubedock Kubedock is an minimal implementation of the docker api that will orchestrate containers on a kubernetes cluster, rather than running contain

Vincent van Dam 66 Jun 14, 2022
Minimal go library for Notion's v1 API

go-notion (beta) go-notion is a minimal Go client library for Notion's v1 API. Check the usage or examples to see how to access Notion's v1 API. NB: N

Ayomide Oyekanmi 17 Apr 15, 2022
Chatto is a minimal chatbot framework in Go.

chatto Simple chatbot framework written in Go, with configurations in YAML. The aim of this project is to create very simple text-based chatbots using

Jaime Tenorio 95 Jun 23, 2022
Hassle-free minimal CI/CD for git repositories with docker or docker-compose projects.

GIT-PIPE Hassle-free minimal CI/CD for git repos for docker-based projects. Features: zero configuration for repos by default automatic encrypted back

Aleksandr Baryshnikov 51 Oct 8, 2021