You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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 only go is officially supported. Regarding it, I think the best is to stick to go, but to evaluate nickel with from go it would be required to have nickel library exporting its capabilities to C ABI and then it would be possible to execute it with using cgo. 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.
The text was updated successfully, but these errors were encountered:
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:
Create a nickel-lang-rs library which asbtract the details of nickel-lang-core, exposing a smaller, simpler, and more stable API
Just make a C compatible wrapper out of 1.
Make a Go wrapper (or really any language out there with C FFI) out of 2.
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.The text was updated successfully, but these errors were encountered: