Hi,
I would like to describe the project structure of Hyperledger Indy and then ask a question.
https://github.com/hyperledger/indy-sdk/tree/master/libindy
The (partial) directory layout is:
indy-sdk /
libindy
src
api
tests
wrappers/rust
Usually after installing system libraries (openssl, sodium) needed you go to libindy and build the library
and then test with RUST_TEST_TASKS=1 cargo test lib
The Rust file in api provide an c-callable API. There are some wrappers for other languages in the wrappers directory. Now integration testing c-callable API is kind-of exhausting, so the maintainers build a Rust wrapper around that as well.
Now we have this wired dependencies that running the integration tests has a dev-dependency outside the libindy directory structure. Please see here: https://github.com/hyperledger/indy-sdk/blob/master/libindy/Cargo.toml#L96
Also in the next line there is a dependency to indy-sys.
This leads to several strange code issues. For example do we have a type IndyHandle in two places:
https://github.com/hyperledger/indy-sdk/blob/master/libindy/src/api/mod.rs#L20
https://github.com/hyperledger/indy-sdk/blob/master/wrappers/rust/src/lib.rs#L40
I am struggling to find a solution. For one I see merit in having rust/wrapper for devs who want a higher-level Rust API instead of what is in libindy/src/api. Secondly in rust/wrappers we have indy-sys for people who installed a system libindy and who don't want to bother with compiling it form themselves.
Then on the other hand there are the integration tests for libindy which benefit from using the wrappers but that leads to this dependency knot.
Axel
Why did I get there?: I want to replace IndyHandle by several newtypes like pub struct CommandHandle(pub i32); and it seems wired to have definitions for them in two places.