Computed Imports

[douglas....@shipwire.com]

Every single time I touch jsonnet, I'm bitten and frustrated by the lack of the ability to do computed imports. It makes me do things in what feels like an unnatural way, like having to load all config from a single file and then grabbing a section by key, rather than splitting into separate files for so many reasons. Is there a workaround for a lack of computed imports yet?

Doug.

[douglas....@shipwire.com]

In order to do what I need to do here, I see that I have two choices.

1. Put everything into a single file, import the whole thing, and extract what I need by key. One file is harder to maintain, and chances of git conflicts are much higher as people all need to edit and commit the same config file.

2. Break config into separate files, which is what I want to do, but then explicitly import every single one of them. This does not scale as adding a new file means modifying the jsonnet library that loads the config. 

Not really liking either of these options.

Douglas.

[Dave Cunningham]

Thanks for your feedback.  Is this related to your question about --ext-code-file yesterday?  I ask because I know Heptio worked around a similar problem by building a dict of all jsonnet files in a given folder, and passing it in with --ext-code.  But in that case the folder had unknown contents.  If the contents are relatively static, can you do the following to have a single import point while breaking stuff into logical files:

// foobar/a.libsonnet

...

// foobar/b.libsonnet

...

// foobar/c.libsonnet

...

// foobar/init.libsonnet

{

  a: import "a.libsonnet";

  b: import "b.libsonnet";

  c: import "c.libsonnet";

}

// client_code1.jsonnet

local foobar = import "foobar/init.libsonnet";

... foobar.b ...

// client_code2.jsonnet

local foobar = import "foobar/init.libsonnet";

... foobar.a ... foobar.c

Alternatively:

// client_code2.jsonnet

local a = (import "foobar/init.libsonnet").a;

local b = (import "foobar/init.libsonnet").c;

... a ... c

or

// client_code2.jsonnet

local foobar = import "foobar/init.libsonnet";

local a = foobar.a;

local b = foobar.c;

... a ... c

There is also a feature request for better syntax (https://github.com/google/jsonnet/issues/307):

// client_code2.jsonnet

local {a, c} = import "foobar/init.libsonnet";  // Doesn't work yet.

... a ... c

Happy to discuss further if this doesn't help

[douglas....@shipwire.com]

David,

I'm trying to load global and environment configuration and merge them together. I want this to be handled by the library. The above suggestion would require that every time a new environment file was added, that someone modify the library. This is akin to updating the library that reads an ini file when a new ini file needs to be read.

It wouldn't be so bad if the environments to load were themselves contained in a config file, but then I'd still have to iterate over those anyway and dynamically load them which puts me back in the same place.

Douglas.

[Alex Clemmer]

We auto-generate this object by *.jsonnet the directory, and pass that in as an --ext-code. That way you don't have to generate it by hand.

--
You received this message because you are subscribed to the Google Groups "Jsonnet" group.
To unsubscribe from this group and stop receiving emails from it, send an email to jsonnet+unsubscribe@googlegroups.com.
To post to this group, send email to jso...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/jsonnet/c0891ab3-1514-4e73-99d5-7da6279248a4%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--

__

Transcribed by my voice-enabled refrigerator, please pardon chilly

messages.

[Dave Cunningham]

It sounds like the only thing that would work for you (short of computed imports) is the ability to import a directory?  And I think the same applies for Alex.

There are a number of design questions with that though:

- should it support *.jsonnet and *.libsonnet or all files?

- should files beginning with a . be included?

- should the same feature exist for importstr

- should there be a single construct to import both strings and jsonnet files?  Should it guess which is which by extension?

The reason we don't want to allow arbitrary computed imports is that it breaks all static analysis, including really useful things like "where is X defined".

To view this discussion on the web visit https://groups.google.com/d/msgid/jsonnet/CAKMv2xw0vEZr6j4UARDdFaBKnJHeW306FGXkh1V6Tn3p%3D16Hvg%40mail.gmail.com.