Consider splitting modules and other libraries into a pure library workspace repository

[mzabaluev]

Crate

ibc
ibc-proto
ibc-relayer

Depending on whether it is meant to be customer-facing:

ibc-telemetry

Summary

It's considered harmful to have dependencies of a customer-facing library locked by Cargo.lock in version control.

Problem Definition

The workspace of the ibc-rs repository has both library crates that, in principle, can have external consumers, as well as the hermes end executable.

it may be a maintenance hazard to have the libraries' dependencies locked by the workspace Cargo.lock in the working trees of the developers working on the libraries themselves. This is the reason why it's not recommended to check in Cargo.lock for pure library crate projects.

Proposal

Consider splitting out the library crates into their own workspace repository.

The dependencies in hermes and other crates can be converted to git dependencies, or (more problematically in the long run) the workspace path dependencies can be rewired via a git submodule.

This does not have to include all library crates in the workspace. As long as there are no outside users of the ibc-relayer library or the telemetry add-on crate, these could stay in the workspace with Hermes.

Acceptance Criteria

A developer of ibc modules, ibc-proto, or other libraries in the project does not have to grapple with modifications to a version-controlled Cargo.lock in order to reach a particular dependency configuration (e.g. the result of cargo update) for the library build, tests, etc.

---

For Admin Use

• Not duplicate issue
• Appropriate labels applied
• Appropriate milestone (priority) applied
• Appropriate contributors tagged
• Contributor assigned/self-assigned

[mzabaluev]

Updated the description to differentiate between ibc modules and Hermes' internal libraries.