This release renames all "library" jsonnet files to .libsonnet as proposed some months ago. This is just a convention, it does not affect evaluation of Jsonnet configs. As with all conventions, users can adopt it... or ignore it :)
This release also has some new language features:
Named params, default arguments
As in Python, you can provide default arguments to functions, e.g.
local add(x, y=3) = x + y;
add(6)
and also bind arguments to parameters by name instead of by position:
add(x=6)
The syntax and semantics matches Python but without _args and *_kwargs.
Top-level arguments
This is a more principled way of parameterizing an entire config. Previously the only way to do that was with `std.extVar`, but this created a global variable of sorts. Code anywhere in the config could use it and it in large configs this can become a maintenance hurdle. `std.extVar` still exists but there is a new way where the parameter is scoped only to the main or root file of the config, and has to be explicitly threaded to imported files:
Previously a Jsonnet file evaluating to a function would be rejected:
$ jsonnet -e 'function() 42'
RUNTIME ERROR: Couldn't manifest function in JSON output.
Now, such a function is called with no arguments to yield the value that is manifested as JSON. To add arguments, use the new commandline parameters.
Available options for specifying values of 'top-level arguments':
Provide the value as a string:
-A / --tla-str <var>[=<val>] If <val> is omitted, get from environment var <var>
--tla-str-file <var>=<file> Read the string from the file
Provide a value as Jsonnet code:
--tla-code <var>[=<code>] If <code> is omitted, get from environment var <var>
--tla-code-file <var>=<file> Read the code from the file
$ jsonnet -e 'function(a, b, c=3) a + b + c' --tla-code a=1 --tla-code b=2
6
Note that TLAs provide default arguments for the entire config, something that was not possible (but often requested) with std.extVar().
Native functions
Now you can, via the C API (or wrappers, e.g. Python) add your own native functions to Jsonnet. The purpose of these functions is to expose tricky functionality that you wouldn't want to implement in Jsonnet. E.g. compression, or encryption. Note that these functions must be pure. They must have no side-effects and must give the same return value for the same input. Since Jsonnet is a lazy language, native functions may be called at unusual times, in an unusual order, more times than expected, or not at all. If the functionality being exposed is not naturally pure (e.g. random secret generation), please wrap it in a cache so that subsequent calls with the same params give the same result.
Currently native extensions can have an arbitrary number of parameters but each has to be a primitive (i.e. not an object or an array). One option for now is to wrap the native function in Jsonnet code that calls std.toString() on the value, then parse the JSON on the host language side.
Native extensions can however return arbitrary JSON objects.