Open olorin37 opened 1 month ago
I agree that a C-compatible facade would be useful in general. The first step is to have first a Rust facade, because as discussed in various channels, nickel-lang-core
is mostly an internal library provided "as it is" and isn't very user-friendly (although it's not too bad either). So how I see it, we should:
nickel-lang-rs
library which asbtract the details of nickel-lang-core
, exposing a smaller, simpler, and more stable API
Problem
Multiple or almost most of DevOps tools are written in go, let's name
terraform
for instance. In its case a provider for reading nickel files to native terraform structures could be written, although providers can be written in any language onlygo
is officially supported. Regarding it, I think the best is to stick togo
, but to evaluate nickel with fromgo
it would be required to have nickel library exporting its capabilities to C ABI and then it would be possible to execute it with usingcgo
. In scope of this project such go package could be prepared similarly to pyckel. (I know about opposite approach where terraform code is defined in nickel and then exported to json which terraform loads, I mean something different). And mind, terraform is just an example.Solution
This project could contain go package implementation which would import nickel library with
cgo
usage, in turn rust code needs to be exported to library with C ABI.cgo
is considered as not performant, but it for described use case it will be absolutely enough.