---
layout: default
title: Tutorial
---
<div class="hgroup">
<div class="hgroup-inline">
<div class="panel">
<h1 id="tutorial">Tutorial</h1>
</div>
<div style="clear: both"></div>
</div>
</div>
<div class="hgroup">
<div class="hgroup-inline">
<div class="panel">
<p>
Let's explore the various features in Jsonnet, and mix some cocktails. All example codes
can be edited, allowing you to experience the language interactively. If you're looking at
Jsonnet for the first time, this is the right place to be. For help using the
implementation, see <a href="getting_started.html">getting started</a>. For a detailed
systematic overview of the language, check out the <a
href="/ref/language.html">reference</a>.
</p>
</div>
<div style="clear: both"></div>
</div>
</div>
<div class="hgroup">
<div class="hgroup-inline">
<div class="panel">
<h2 id="syntax">Syntax</h2>
</div>
<div style="clear: both"></div>
</div>
</div>
<div class="hgroup">
<div class="hgroup-inline">
<div class="panel">
<p>
Any <a href="https://json.org">JSON</a> document is a valid Jsonnet program, so we'll focus
on what Jsonnet adds to JSON. Let's start with an example that does not involve any
computation but uses new syntax.
</p>
<ul>
<li>Fields that happen to be valid identifiers have no quotes</li>
<li><i>Trailing</i> commas at the end of arrays / objects</li>
<li>Comments</li>
<li>
String literals use <code>"</code> or <code>'</code>. The single quote is easier on the
eyes but either can be used to avoid escaping the other, e.g. <code>"Farmer's Gin"</code>
instead of <code>'Farmer\'s Gin'</code>.
</li>
<li>
Text blocks <code>|||</code> allow verbatim text across multiple lines.
</li>
<li>
Verbatim strings <code>@'foo'</code> and <code>@"foo"</code> are for single lines.
</li>
</ul>
<p>
Using the interactive demo below, try modifying the strings / quantities. Try adding a "Dry
Manhattan" which uses dry red vermouth and is garnished with a lemon slice.
</p>
</div>
<div style="clear: both"></div>
</div>
</div>
{% include demo.inc name="syntax" %}
<div class="hgroup">
<div class="hgroup-inline">
<div class="panel">
<h2 id="variables">Variables</h2>
</div>
<div style="clear: both"></div>
</div>
</div>
<div class="hgroup">
<div class="hgroup-inline">
<div class="panel">
<p>
Variables are the simplest way to avoid duplication.
</p>
<ul>
<li>The <code>local</code> keyword defines a variable.</li>
<li>Variables defined next to fields end with a comma (<code>,</code>).</li>
<li>All other cases end with a semicolon (<code>;</code>).</li>
</ul>
<p>
Try factoring out <code>"Simple Syrup"</code> to the top level or to the same level as
the <code>pour</code> variable.
</p>
</div>
<div style="clear: both"></div>
</div>
</div>
{% include demo.inc name="variables" %}
<div class="hgroup">
<div class="hgroup-inline">
<div class="panel">
<h2 id="references">References</h2>
</div>
<div style="clear: both"></div>
</div>
</div>
<div class="hgroup">
<div class="hgroup-inline">
<div class="panel">
<p>
Another way to avoid duplication is to refer to another part of the structure.
</p>
<ul>
<li><code>self</code> refers to the current object.</li>
<li><code>$</code> refers to the outer-most object.</li>
<li><code>['foo']</code> looks up a field.</li>
<li><code>.f</code> can be used if the field name is an identifier.</li>
<li><code>[10]</code> looks up an array element.</li>
<li>Arbitrarily long paths are allowed.</li>
<li>Array slices like <code>arr[10:20:2]</code> are allowed, like in Python.</li>
<li>Strings can be looked up / sliced too, by unicode codepoint.</li>
</ul>
<p>
Another name for a Tom Collins is a Gin Fizz. Try adding an alias for that.
</p>
</div>
<div style="clear: both"></div>
</div>
</div>
{% include demo.inc name="references" %}
<div class="hgroup">
<div class="hgroup-inline">
<div class="panel">
<p>
In order to refer to objects between the current and outer-most object, we use a variable to
create a name for that level:
</p>
</div>
<div style="clear: both"></div>
</div>
</div>
{% include demo.inc name="inner-reference" %}
<div class="hgroup">
<div class="hgroup-inline">
<div class="panel">
<h2 id="arithmetic">Arithmetic</h2>
</div>
<div style="clear: both"></div>
</div>
</div>
<div class="hgroup">
<div class="hgroup-inline">
<div class="panel">
<p>
Arithmetic includes numeric operations like multiplication but also various operations on
other types.
</p>
<ul>
<li>Use floating point arithmetic, bitwise ops, boolean logic.</li>
<li>
Strings may be concatenated with <code>+</code>, which implicitly converts
one operand to string if needed.
</li>
<li>Two strings can be compared with <code><</code> (unicode codepoint order).</li>
<li>
Objects may be combined with <code>+</code> where the right-hand side wins field
conflicts.
</li>
<li>Test if a field is in an object with <code>in</code>.</li>
<li><code>==</code> is deep value equality.</li>
<li>Python-compatible string formatting is available via <code>%</code>. When combined with
<code>|||</code> this can be used for templating text files.</li>
</ul>
<p>Try dividing by zero to see what happens.</p>
</div>
<div style="clear: both"></div>
</div>
</div>
{% include demo.inc name="arith" %}
<div class="hgroup">
<div class="hgroup-inline">
<div class="panel">
<h2 id="functions">Functions</h2>
</div>
<div style="clear: both"></div>
</div>
</div>
<div class="hgroup">
<div class="hgroup-inline">
<div class="panel">
<p>
Like Python, functions have positional parameters, named parameters, and default arguments.
Closures are also supported. The examples below should demonstrate the syntax. Many
functions are already defined in the <a href=/ref/stdlib.html>standard library</a>.
</p>
<p>
Try writing a function <code>is_even</code> that uses the modulo operator <code>%</code> and
returns either true or false.
</p>
</div>
<div style="clear: both"></div>
</div>
</div>
{% include demo.inc name="functions" %}
<div class="hgroup">
<div class="hgroup-inline">
<div class="panel">
<p>
And here's an example with cocktails.
</p>
</div>
<div style="clear: both"></div>
</div>
</div>
{% include demo.inc name="sours" %}
<div class="hgroup">
<div class="hgroup-inline">
<div class="panel">
<h2 id="conditionals">Conditionals</h2>
</div>
<div style="clear: both"></div>
</div>
</div>
<div class="hgroup">
<div class="hgroup-inline">
<div class="panel">
<p>
Conditional expressions look like <code>if b then e else e</code>. The
<code>else</code> branch is optional and defaults to <code>null</code>.
</p>
<p>
Try adding the missing Large Virgin Mojito:
</p>
</div>
<div style="clear: both"></div>
</div>
</div>
{% include demo.inc name="conditionals" %}
<div class="hgroup">
<div class="hgroup-inline">
<div class="panel">
<h2 id="computed_field_names">Computed Field Names</h2>
</div>
<div style="clear: both"></div>
</div>
</div>
<div class="hgroup">
<div class="hgroup-inline">
<div class="panel">
<p>
Jsonnet objects can be used like a <code>std::map</code> or similar datastructures from
regular languages.
</p>
<ul>
<li>Recall that a field lookup can be computed with <code>obj[e]</code></li>
<li>The definition equivalent is <code>{[e]: </code>... <code>}</code></li>
<li>
<code>self</code> or object locals cannot be accessed when field names are being computed,
since the object is not yet constructed.
</li>
<li>
If a field name evaluates to <code>null</code> during object construction, the field is
omitted. This works nicely with the default false branch of a conditional (see below).
</li>
</ul>
<p>
Try adding <code>[self.f]: 'f'</code> to see what happens, while pondering what that
could even mean!
</p>
</div>
<div style="clear: both"></div>
</div>
</div>
{% include demo.inc name="computed-fields" %}
<div class="hgroup">
<div class="hgroup-inline">
<div class="panel">
<h2 id="comprehension">Array and Object Comprehension</h2>
</div>
<div style="clear: both"></div>
</div>
</div>
<div class="hgroup">
<div class="hgroup-inline">
<div class="panel">
<p>
What if you want to make an array or object and you don't know how many elements / fields
they will have at run-time? Jsonnet has Python-style array and object comprehension
constructs to allow this.
</p>
<ul>
<li>Any nesting of <code>for</code> and <code>if</code> can be used.</li>
<li>The nest behaves like a loop nest, although the body is written first.</li>
</ul>
</div>
<div style="clear: both"></div>
</div>
</div>
{% include demo.inc name="comprehensions" %}
<div class="hgroup">
<div class="hgroup-inline">
<div class="panel">
<p>
Below, a less contrived example. The first cocktail has equal parts of three ingredients.
The second iterates over an array of records - name prefix and fruit juice.
</p>
<p>
Try adding a "Red Screwdriver" with cranberry juice.
</p>
</div>
<div style="clear: both"></div>
</div>
</div>
{% include demo.inc name="cocktail-comprehensions" %}
<div class="hgroup">
<div class="hgroup-inline">
<div class="panel">
<h2 id="imports">Imports</h2>
</div>
<div style="clear: both"></div>
</div>
</div>
<div class="hgroup">
<div class="hgroup-inline">
<div class="panel">
<p>
It's possible to import both code and raw data from other files.
</p>
<ul>
<li>The <code>import</code> construct is like copy/pasting Jsonnet code.</li>
<li>Files designed for import by convention end with <tt>.libsonnet</tt></li>
<li>Raw JSON can be imported this way too.</li>
<li>The <code>importstr</code> construct is for verbatim UTF-8 text.</li>
</ul>
<p>
Usually, imported Jsonnet content is stashed in a top-level local variable. This
resembles the way other programming languages handle modules. Jsonnet libraries typically
return an object, so that they can easily be extended. Neither of these conventions are
enforced.
</p>
<p>
Try including the Cosmopolitan from the library.
</p>
</div>
<div style="clear: both"></div>
</div>
</div>
<div class="inverse hgroup">
<div class=hgroup-inline>
<div class="tab-window-input" id="imports-input">
<div class="tab-header">
</div>
<textarea id=imports-jsonnet>
{% include examples/imports.jsonnet %}
</textarea>
<textarea id=martinis-libsonnet>
{% include examples/martinis.libsonnet %}
</textarea>
<textarea id=garnish-txt>
{% include examples/garnish.txt %}
</textarea>
</div>
<div class="bigarrow">➡</div>
<div class="tab-window-output" id="imports-output">
<div class="tab-header">
<div class=selected onclick="tab_output_click(this, 'imports-json-output')">output.json</div>
</div>
<textarea readonly class="selected code-json" id="imports-json-output">
{% include examples/imports.jsonnet.golden %}
</textarea>
</div>
<script>
demo(
'imports-input',
{
'imports-jsonnet': 'imports.jsonnet',
'martinis-libsonnet': 'martinis.libsonnet',
'garnish-txt': 'garnish.txt',
},
'imports.jsonnet',
'imports-output',
false,
false
);
</script>
<div style="clear: both"></div>
</div>
</div>
<div class="hgroup">
<div class="hgroup-inline">
<div class="panel">
<p>
The following example shows how to write libraries of functions. It also shows how to
define a local variable in the scope of a function. Try adding the Bee's Knees from above
using the utility library.
</p>
</div>
<div style="clear: both"></div>
</div>
</div>
<div class="inverse hgroup">
<div class=hgroup-inline>
<div class="tab-window-input" id="negroni-input">
<div class="tab-header">
</div>
<textarea id=negroni-jsonnet>
{% include examples/negroni.jsonnet %}
</textarea>
<textarea id=utils-libsonnet>
{% include examples/utils.libsonnet %}
</textarea>
</div>
<div class="bigarrow">➡</div>
<div class="tab-window-output" id="negroni-output">
<div class="tab-header">
<div class=selected onclick="tab_output_click(this, 'negroni-json-output')">output.json</div>
</div>
<textarea readonly class="selected code-json" id="negroni-json-output">
{% include examples/negroni.jsonnet.golden %}
</textarea>
</div>
<script>
demo(
'negroni-input',
{
'negroni-jsonnet': 'negroni.jsonnet',
'utils-libsonnet': 'utils.libsonnet',
},
'negroni.jsonnet',
'negroni-output',
false,
false
);
</script>
<div style="clear: both"></div>
</div>
</div>
<div class="hgroup">
<div class="hgroup-inline">
<div class="panel">
<h2 id="errors">Errors</h2>
</div>
<div style="clear: both"></div>
</div>
</div>
<div class="hgroup">
<div class="hgroup-inline">
<div class="panel">
<p>
Errors can arise from the language itself (e.g. an array overrun) or thrown from Jsonnet
code. Stack traces provide context for the error.
</p>
<ul>
<li>To raise an error: <code>error "foo"</code></li>
<li>To assert a condition before an expression: <code>assert "foo";</code></li>
<li>A custom failure message: <code>assert "foo" : "message";</code></li>
<li>Assert fields have a property: <code>assert self.f == 10,</code></li>
<li>With custom failure message: <code>assert "foo" : "message",</code></li>
</ul>
<p>
Try modifying the code below to trigger the assertion failures, and observe the error
messages and stack traces that result.
</p>
<p>
You might wonder why the divide-by-zero is not triggered in the equal_parts function, since
that code occurs before the <code>std.length()</code> check. Jsonnet is a lazy
language, so variable initializers are not evaluated until the variable is used. Evaluation
order is very hard to notice. It only becomes relevant when code throws errors, or takes a
long time to execute. For more discussion of laziness, see <a
href=/articles/design.html>design rationale</a>.
</p>
</div>
<div style="clear: both"></div>
</div>
</div>
{% include demo.inc name="error-examples" %}
<div class="hgroup">
<div class="hgroup-inline">
<div class="panel">
<h2 id="parameterize-entire-config">Parameterize Entire Config</h2>
</div>
<div style="clear: both"></div>
</div>
</div>
<div class="hgroup">
<div class="hgroup-inline">
<div class="panel">
<p>
Jsonnet is hermetic: It always generates the same data no matter the execution environment.
This is an important property but there are times when you want a few carefully chosen
parameters at the top level. There are two ways to do this, with different properties.
</p>
<ul>
<li>
<b>External variables</b>, which are accessible anywhere in the config, or any file,
using <code>std.extVar("foo")</code>.
</li>
<li>
<b>Top-level arguments</b>, where the whole config is expressed as a function.
</li>
</ul>
<p>
To illustrate the differences, We'll show how the same example is expressed in each case.
</p>
</div>
<div style="clear: both"></div>
</div>
</div>
<div class="hgroup">
<div class="hgroup-inline">
<div class="panel">
<h3 id="parameterize-entire-config">External variables</h3>
</div>
<div style="clear: both"></div>
</div>
</div>
<div class="hgroup">
<div class="hgroup-inline">
<div class="panel">
<p>
The following example binds two external variables, listed below. Any Jsonnet value can be
bound to an external variable, even functions.
</p>
<ul>
<li><code>prefix</code> is bound to the string <code>"Happy Hour "</code></li>
<li><code>brunch</code> is bound to <code>true</code></li>
</ul>
<p>
The values are configured when the Jsonnet virtual machine is initialized, by passing either
1) Jsonnet code (which evaluates to the value), 2) or a raw string. The latter is just a
convenience, because escaping a string to pass it as Jsonnet code can be tedious. To make
this concrete, the above variables can be configured with the following commandline:
</p>
<pre>jsonnet --ext-str prefix="Happy Hour " \
--ext-code brunch=true ...
</pre>
</div>
<div style="clear: both"></div>
</div>
</div>
<div class="inverse hgroup">
<div class=hgroup-inline>
<div class="tab-window-input" id="top-level-ext-input">
<div class="tab-header">
</div>
<textarea id=top-level-ext-jsonnet>
{% include examples/top-level-ext.jsonnet %}
</textarea>
<textarea id=library-ext-libsonnet>
{% include examples/library-ext.libsonnet %}
</textarea>
</div>
<div class="bigarrow">➡</div>
<div class="tab-window-output" id="top-level-ext-output">
<div class="tab-header">
<div class=selected onclick="tab_click(this, 'top-level-ext-json-output')">output.json</div>
</div>
<textarea readonly class="selected code-json" id="top-level-ext-json-output">
{% include examples/top-level-ext.jsonnet.golden %}
</textarea>
</div>
<script>
demo(
'top-level-ext-input',
{
'top-level-ext-jsonnet': 'top-level-ext.jsonnet',
'library-ext-libsonnet': 'library-ext.libsonnet',
},
'top-level-ext.jsonnet',
'top-level-ext-output',
false,
false,
{
ext_str: {
prefix: 'Happy Hour ',
},
ext_code: {
brunch: 'true',
},
}
);
</script>
<div style="clear: both"></div>
</div>
</div>
<div class="hgroup">
<div class="hgroup-inline">
<div class="panel">
<h3 id="parameterize-entire-config">Top-level arguments</h3>
</div>
<div style="clear: both"></div>
</div>
</div>
<div class="hgroup">
<div class="hgroup-inline">
<div class="panel">
<p>
Alternatively the same code can be written using top-level arguments, where the whole config
is written as a function. How does this differ to using external variables?
</p>
<ul>
<li>Values must be explicitly threaded through files</li>
<li>Default values can be provided</li>
<li>A config with top-level arguments can also be imported as a library and called as a
function with parameters passed in</li>
</ul>
<p>
Generally, top-level arguments are the safer and easier way to parameterize an entire
config, because the variables are not global and it's clear what parts of the config
are dependent on their environment. However, they do require more explicit threading of
the values into other imported code. Here's the equivalent invocation of the Jsonnet
command-line tool:
</p>
<pre>jsonnet --tla-str prefix="Happy Hour " \
--tla-code brunch=true ...
</pre>
</div>
<div style="clear: both"></div>
</div>
</div>
<div class="inverse hgroup">
<div class=hgroup-inline>
<div class="tab-window-input" id="top-level-tla-input">
<div class="tab-header">
</div>
<textarea id=top-level-tla-jsonnet>
{% include examples/top-level-tla.jsonnet %}
</textarea>
<textarea id=library-tla-libsonnet>
{% include examples/library-tla.libsonnet %}
</textarea>
</div>
<div class="bigarrow">➡</div>
<div class="tab-window-output" id="top-level-tla-output">
<div class="tab-header">
<div class=selected onclick="tab_click(this, 'top-level-tla-json-output')">output.json</div>
</div>
<textarea readonly class="selected code-json" id="top-level-tla-json-output">
{% include examples/top-level-tla.jsonnet.golden %}
</textarea>
</div>
<script>
demo(
'top-level-tla-input',
{
'top-level-tla-jsonnet': 'top-level-tla.jsonnet',
'library-tla-libsonnet': 'library-tla.libsonnet',
},
'top-level-tla.jsonnet',
'top-level-tla-output',
false,
false,
{
tla_str: {
prefix: 'Happy Hour ',
},
tla_code: {
brunch: 'true',
},
}
);
</script>
<div style="clear: both"></div>
</div>
</div>
<div class="hgroup">
<div class="hgroup-inline">
<div class="panel">
<h2 id="oo">Object-Orientation</h2>
</div>
<div style="clear: both"></div>
</div>
</div>
<div class="hgroup">
<div class="hgroup-inline">
<div class="panel">
<p>
In general, object-orientation makes it easy to define many variants from a single "base".
Unlike Java, C++ and Python, where classes extend other classes, in Jsonnet, objects extend
other objects. We have already discussed some of the raw ingredients for this, albeit in
isolation:
</p>
<ul>
<li>Objects (which we inherit from JSON)</li>
<li>The <dfn>object composition</dfn> operator <code>+</code>, which merges two objects,
choosing the right hand side when fields collide</li>
<li>The <code>self</code> keyword, a reference to the current object</li>
</ul>
<p>
When these features are combined together and with the following <i>new</i> features, things
get a lot more interesting:
</p>
<ul>
<li>Hidden fields, defined with <code>::</code>, which do not appear in generated JSON</li>
<li>The <code>super</code> keyword, which has its usual meaning</li>
<li>The <code>+:</code> field syntax for overriding deeply nested fields</li>
</ul>
</div>
<div style="clear: both"></div>
</div>
</div>
<div class="hgroup">
<div class="hgroup-inline">
<div class="panel">
<p>
The following example is contrived but demonstrates a few of the features using the
classical language of object-orientation, "derived" and "base".
</p>
</div>
<div style="clear: both"></div>
</div>
</div>
{% include demo.inc name="oo-contrived" %}
<div class="hgroup">
<div class="hgroup-inline">
<div class="panel">
<p>
Let's make it more concrete by mixing deriving some cocktails that are quite similar from a
template that draws out their similarities. The <code>+</code> operator is actually
implicit in these examples. In the common case where you write <code>foo + {
</code>...<code> }</code>, i.e. the <code>+</code> is immediately followed by a
<code>{</code>, then the <code>+</code> can be elided. Try explicitly adding the + in the 4
cases, below.
</p>
</div>
<div style="clear: both"></div>
</div>
</div>
<div class="inverse hgroup">
<div class=hgroup-inline>
<div class="tab-window-input" id="sours-oo-input">
<div class="tab-header">
</div>
<textarea id=sours-oo-jsonnet>
{% include examples/sours-oo.jsonnet %}
</textarea>
<textarea id=templates-libsonnet>
{% include examples/templates.libsonnet %}
</textarea>
</div>
<div class="bigarrow">➡</div>
<div class="tab-window-output" id="sours-oo-output">
<div class="tab-header">
<div class=selected onclick="tab_output_click(this, 'sours-oo-json-output')">output.json</div>
</div>
<textarea readonly class="selected code-json" id="sours-oo-json-output">
{% include examples/sours-oo.jsonnet.golden %}
</textarea>
</div>
<script>
demo(
'sours-oo-input',
{
'sours-oo-jsonnet': 'sours-oo.jsonnet',
'templates-libsonnet': 'templates.libsonnet',
},
'sours-oo.jsonnet',
'sours-oo-output',
false,
false
);
</script>
<div style="clear: both"></div>
</div>
</div>
<div class="hgroup">
<div class="hgroup-inline">
<div class="panel">
<p>
The key to making Jsonnet object-oriented is that the <code>self</code> keyword is "late
bound". In other words, <code>self.foo</code> can have its meaning altered by overriding it
on the right hand side of a <code>+</code>. This would not be the case in a simple "object
merge" semantics of <code>+</code>, where <code>self.foo</code> would be fully evaluated to
a concrete value before we did the <code>+</code>. In the above example, the left hand side
of the <code>+</code> is <code>templates.Sour</code> (the <code>+</code> is implicit) and
the right hand side is an object that overrides <code>spirit</code>. So in the
<code>templates.Sour</code> definition (in <tt>templates.libsonnet</tt>) that causes the
reference to <code>drink.spirit</code> in the ingredients list to return
<code>"Whiskey"</code> rather than raise the error <code>'Must override "spirit"'</code>.
</p>
<p>
Most of the abstraction in the above example could have been achieved with functions instead
of object-orientation. Indeed, last time we spoke about sours, we used functions for that
very purpose. In general, the choice of whether to use functions or object-orientation is
quite a complex one, and can be driven as much by instinct as by anything else. The most
obvious difference is that with object-orientation, you can override any file from the
resulting object, whereas with functions you can only pass arguments for the specific
parameters of the function. So, e.g., if the <code>templates.Sour</code> had been
implemented as a function that did not parameterize the ingredients list in general way,
then it would not have been possible to add that extra ingredient to form the Nor'Easter.
</p>
<p>
So far, every example has used a literal object on the right hand side of the
<code>+</code>. This is consistent with the majority of object-oriented languages. But
Jsonnet is more general in that is has <a
href="http://www.bracha.org/oopsla90.pdf">mixins</a>. A Mixin allows you to take some
"overrides" and instead of just applying them to an existing object to get a new object, you
can pass them around as a first class value and apply them to any object you want. The
following example shows mixins being used to modify cocktails in a general way:
</p>
</div>
<div style="clear: both"></div>
</div>
</div>
<div class="inverse hgroup">
<div class=hgroup-inline>
<div class="tab-window-input" id="mixins-input">
<div class="tab-header">
</div>
<textarea id=mixins-jsonnet>
{% include examples/mixins.jsonnet %}
</textarea>
<textarea id=sours-oo-jsonnet2>
{% include examples/sours-oo.jsonnet %}
</textarea>
<textarea id=templates-libsonnet2>
{% include examples/templates.libsonnet %}
</textarea>
</div>
<div class="bigarrow">➡</div>
<div class="tab-window-output" id="mixins-output">
<div class="tab-header">
<div class=selected onclick="tab_output_click(this, 'mixins-json-output')">output.json</div>
</div>
<textarea readonly class="selected code-json" id="mixins-json-output">
{% include examples/mixins.jsonnet.golden %}
</textarea>
</div>
<script>
demo(
'mixins-input',
{
'mixins-jsonnet': 'mixins.jsonnet',
'sours-oo-jsonnet2': 'sours-oo.jsonnet',
'templates-libsonnet2': 'templates.libsonnet',
},
'mixins.jsonnet',
'mixins-output',
false,
false
);
</script>
<div style="clear: both"></div>
</div>
</div>
<div class="hgroup">
<div class="hgroup-inline">
<div class="panel">
<p>
Thank you for completing the Jsonnet tutorial! We hope you enjoyed the accompanying
beverages. At this point, you should be able to build concoctions of your own. If you want
to read about the Jsonnet language in greater and more systematic detail, we recommend the
language <a href="/ref/language.html">reference</a>.
</p>
</div>
<div style="clear: both"></div>
</div>
</div>
<div class="hgroup">
<div class="hgroup-inline">
<div class="panel">
</div>
<div style="clear: both"></div>
</div>
</div>