this uses the mock server rather than the ffi tho

@Matt (pactflow.io / pact-js / pact-go) now that i followed from what yousaf said, I need to use the pact crates and sort of export these functions as what is known as ‘nif’ in erlang. I did follow these: 1. https://medium.com/@brucifi/writing-your-first-erlang-nif-in-rust-274374094207 2. https://github.com/elitau/pact_elixir/blob/master/native/pactmockserver/src/lib.rs After following article 1, i was able to build these crates, but when i introduced rustler:init! and rustler::nif macros, i am getting this:

<<"code">> =>
                                  #{<<"code">> => <<"E0277">>,
                                    <<"explanation">> =>
                                        <<"You tried to use a type which doesn't implement some trait in a place which\nexpected that trait.\n\nErroneous code example:\n\n```compile_fail,E0277\n// here we declare the Foo trait with a bar method\ntrait Foo {\n    fn bar(&self);\n}\n\n// we now declare a function which takes an object implementing the Foo trait\nfn some_func<T: Foo>(foo: T) {\n    foo.bar();\n}\n\nfn main() {\n    // we now call the method with the i32 type, which doesn't implement\n    // the Foo trait\n    some_func(5i32); // error: the trait bound `i32 : Foo` is not satisfied\n}\n```\n\nIn order to fix this error, verify that the type you're using does implement\nthe trait. Example:\n\n```\ntrait Foo {\n    fn bar(&self);\n}\n\n// we implement the trait on the i32 type\nimpl Foo for i32 {\n    fn bar(&self) {}\n}\n\nfn some_func<T: Foo>(foo: T) {\n    foo.bar(); // we can now use this method since i32 implements the\n               // Foo trait\n}\n\nfn main() {\n    some_func(5i32); // ok!\n}\n```\n\nOr in a generic context, an erroneous code example would look like:\n\n```compile_fail,E0277\nfn some_func<T>(foo: T) {\n    println!(\"{:?}\", foo); // error: the trait `core::fmt::Debug` is not\n                           //        implemented for the type `T`\n}\n\nfn main() {\n    // We now call the method with the i32 type,\n    // which *does* implement the Debug trait.\n    some_func(5i32);\n}\n```\n\nNote that the error here is in the definition of the generic function. Although\nwe only call it with a parameter that does implement `Debug`, the compiler\nstill rejects the function. It must work with all possible input types. In\norder to make this example compile, we need to restrict the generic type we're\naccepting:\n\n```\nuse std::fmt;\n\n// Restrict the input type to types that implement Debug.\nfn some_func<T: fmt::Debug>(foo: T) {\n    println!(\"{:?}\", foo);\n}\n\nfn main() {\n    // Calling the method is still fine, as i32 implements Debug.\n    some_func(5i32);\n\n    // This would fail to compile now:\n    // struct WithoutDebug;\n    // some_func(WithoutDebug);\n}\n```\n\nRust only looks at the signature of the called function, as such it must\nalready specify all requirements that will be used for every type parameter.\n">>},
                              <<"level">> => <<"error">>,
                              <<"message">> =>
                                  <<"the trait bound `anyhow::Error: Encoder` is not satisfied">>,

In short I tried this:

#[rustler::nif(name = "create_mock_server")]
pub fn create_mock_server(
  pact_json: &str,
  addr: std::net::SocketAddr
) -> anyhow::Result<i32> {

but this seems to fail this cargo build process

hmm does any of the commentary in https://docs.pact.io/slack/pact-elixir.html help?

Ah, still needed NIF but pre-built (which is good, it would suck that users need a rust runtime to run Elixir)

Hi all, here is an update on the current status of Elixir bindings as of October 2021, and the next steps for developing the library. HIGH-LEVEL WORK TO BE DONE The https://github.com/elitau/pact_elixir library is a community-built implementation of Pact in Elixir. Thank you to @pact-slack for the great work on this library so far! In order to make the library fully-featured, we have these general tasks to complete: ? Change the Elixir FFI implementation (see details below) ? Re-implement consumer-side mocks with new FFI ? Implement provider verification ? Implement messaging equivalents ? Implement other workflows like publishing and downloading pacts from a broker FFI: PROBLEM AND CONSTRAINTS The pact_elixir library currently uses a Elixir+Rust library called https://github.com/rusterlium/rustler to create safe bindings between the Elixir wrapper and the Rust reference implementation of Pact. Rustler is a great library for creating interop between the two languages because it minimizes the risks of FFI. However, rustler requires the app developer to have a Rust toolchain installed, and to compile the core Rust code at the same time as the app and the pact_elixir library are compiled. This leads to more system dependencies and slower build performance. The developer should not need to know that the internals of pact_elixir are actually written in a different language. The Elixir and Erlang ecosystem has another FFI concept called NIFs, or Natively-Implemented Functions. Note that NIFs require special instrumentation of the native code in order to communicate properly with the Elixir bindings that are calling in. This does not seem like an ideal solution either, because it requires the pact_elixir library to maintain hand-written shim code in C to add this instrumentation. FFI: NEXT STEPS We intend to follow the same approach that pact-js and pact-go now follow: the pact_elixir library should download the FFI bundles for each OS architecture at library publish time, and then link to them using whatever strategy is most unobtrusive to the app developer. We can reuse the pipeline scripts from these other implementations in order to download the bundles. We need to pick an appropriate FFI strategy from the Elixir/Erlang ecosystem to allow a good developer experience. Rustler and handwritten NIF instrumentation do not seem to be good options. Erlang Ports or Port Drivers may be viable options. We may also be able to find a library to automatically generate NIF bindings around the FFI bundles, and if this is possible, this may be the best option. I am not very familiar with this part of the Elixir and Erlang ecosystem, so if anyone is more familiar with what is available, please share what you know! Once we have researched and picked the right FFI strategy, we can create the bindings and have a fully-featured Elixir implementation of Pact! RESOURCES ? https://github.com/elitau/pact_elixir: Elixir bindings for Pact, let?s focus our efforts to evolve this repo! ? https://hex.pm: package manager for the ecosystem ? https://erlang.org/doc/tutorial/users_guide.html: Erlang Interoperability Tutorial User?s Guide, explains NIFs, ports, port drivers, etc. ? https://sudonull.com/post/97911-How-to-write-your-NIF-in-Elixir: Tutorial on writing NIFs. Note that the C code requires instrumentation, so hand-writing a NIF is likely not our best option.

Excuse the bad formatting, but this is where it seemed we landed

I read this as pre-compile NIFs and distribute those to users (to avoid users having to compile rust). So you might be on the right path. It looks like some types need additional traits, which is why the compilation is failing

even tried using

erlang:load_nif/2

but the same error comes as

no driver init

Also https://www.erlang.org/doc/tutorial/nif.html