Subcommand for applying functions to commandline arguments

[fuzzypixelz]

Subcommand for applying functions to commandline arguments

[yannham]

Hi @fuzzypixelz 🙂 nice to hear from you again!

It's a bit of a shame because there's no good place where this feature is documented currently, but we've implemented since 1.3 (I believe) something call the CLI customize mode. The idea is exactly what you describe: be able to pass arguments to Nickel configurations from the command-line.

As Nickel focuses on the merging model to write reusable configuration modules, it's based on record, and not function, but can achieve the same.

If you take any configuration, you can enter the customize mode by adding a -- after the subcommand. For example:

$ nickel eval examples/config-gcc/config-gcc.ncl -- help
[..print help..]

The idea is that this mode turns your configuration into a CLI, so to speak. You can then pass arguments using Nickel syntax (but don't forget to escape shell characters) like foo.bar=1 or 'input.str="Hello"'. A basic example that would mimic your function idea would be:

# file: config.ncl
let Output = Dyn in
let Contract = Dyn in

{
  input.json_data | String,
  output | Output =
    let result | Contract = std.deserialize 'Json input.json_data in
    std.deep_seq result 'Ok,
}

$ nickel eval config.ncl --field output -- 'input.json_data="{\"foo\": 1}"'
'Ok

So I think this should cover your use-case.

[fuzzypixelz]

Thanks for the response! 😄

Needless to say, I didn't know about the customize mode. The CLI still shows help if I use it incorrectly, but I don't think the option is discoverable IIRC or I must've misread the CLI usage info (to be checked) it is mentioned when executing nickel eval --help, I simply missed it.

In any case, I think it's an imperfect solution because the caller needs to escape Nickel escape codes by hand when passing strings. The logic behind string escape codes is the responsibility of the interpreter.

Still, this is unfair to the interface because it's supposed to accept Nickel expressions and not strings. Would you be interested in adding a syntax to pass in raw strings? Or perhaps simply add raw strings to the language?

[yannham]

In any case, I think it's an imperfect solution because the caller needs to escape Nickel escape codes by hand when passing strings. The logic behind string escape codes is the responsibility of the interpreter.

I think there are two different aspects here. The fact that we need to escape " inside a string sounds unrelated to the CLI interface. We have to do that in Nickel source files as well. Typically, you couldn't copy-paste the JSON content directly in a String inside a .ncl file without escaping either.

As you say, what the customize mode accepts is just normal Nickel expressions, and IMHO that makes sense, because I think you want to distinguish between 2 and "2".

One possible nice addition would be to use the special value - to mean "take from stdin", and this could be considered a String by default. Or we could have a special syntax to do so, like -String- or whatever. This doesn't cover all use-cases but is probably a nice addition when you want to forward a generated string to a Nickel configuration.

A second point is the fact that you need to also escape shell special characters. Most of the time you can get by, by just slapping a pair of single quotes around the whole affectation on the CLI, as I did in my example. I honestly don't see how to avoid that anyway, as your input method is the terminal.

Still, this is unfair to the interface because it's supposed to accept Nickel expressions and not strings. Would you be interested in adding a syntax to pass in raw strings? Or perhaps simply add raw strings to the language?

Adding raw strings to the language would make a lot of sense, yeah. We already have the machinery for special strings xxx%" "%, so it would just amount to have a r prefix I suppose, like r%"..."%.

Shall we close this issue, and open other ones if needed (raw strings or the - argument)? I think the the original issue of passing arguments is possible in current Nickel, but could be improved by those tangential additions.

[fuzzypixelz]

Yes I think we can close this now. I'm not very sure about the - argument since it is less useful for multiple arguments. And it parts with the idea of "put any Nickel expression here", so it's a more consequential change. I'll open an issue for raw strings. If you also want the - argument let's do that too.