How do I specify a file to embed into result with nickel export?

[vi]

I want the output to contain blobs taken from user-specified files.

Currently they are just imported from txt files as strings (with hard coded names), but how do I make it parametrizable?

The blobs are big and are not appropriate for inlining as usual customization parameters.

Are there good ways, apart from obvious workaround to generates Nickel code to a temporary file?
(is it by the way idiomatic for a Nickel script to generate another Nickel script?)

[yannham]

If I understand correctly, what you're looking for is a kind of import 'Text but where the filename might not be known statically? Like a std.read_file, for example?

[vi]

Maybe CLI can include something like customization mode, but that reads the file (or env var) and places it into a field using merge?

Pseudocode:

nickel export mycode.ncl -- \
    --text-field [email protected] \
    --json-field [email protected]  \
    --text-field short_line=Hello \
    --text-field user_home_directory=\$HOME

Current customisation mechanism also makes it nontrivial to include untrusted, user-supplied text as a string variable, so that --text-field can be useful even without reading files.

How to specify the source (literal, file, envvar) - i.e. sigils or separate options is up to bikeschedding.

[yannham]

That's also a possibility, yes - especially because the values provided to the configuration in the customize mode (to the right of the = sign) are interpreted as normal Nickel syntax, so we can use anything that isn't valid Nickel as an extension, like your @something. That might be nicer than having a separate CLI argument for each.

[vi]

Found another way:

nickel export ... -- the_blob='(import '\''Raw "the_blob.dat")'

So maybe all is needed is just a more syntax sugar in CLI to avoid all those quotes?

[yannham]

Ah yes, I haven't thought about that - you could even interpolate a shell variable here and make it truly parametric, but from the Nickel POV it's still statically known because when the program start the file to import is fixed. As for environment variable, we could just have a nice wrapper around that as well, indeed

[vi]

The main thing is preventing the need to escape, i.e. handling the

nickel ... nickname="\"$UNTRUSTED_USER_INPUT\""

, where the input may be %{let rec a = fun x => a x in "%{a 5}"}