trussed icon indicating copy to clipboard operation
trussed copied to clipboard

Revisit module structure and re-exports

Open robin-nitrokey opened this issue 11 months ago • 4 comments

When working on splitting Trussed into a client API and a backend implementation, I noticed the following:

Currently, many types that are declared in Trussed are re-exported in multiple locations. For example, the Platform trait:

  • defined in platform::Platform
  • re-exported as Platform (top-level)
  • re-exported as types::Platform

External types are also re-exported in multiple locations:

  • platform re-exports rand_core::{CryptoRng, RngCore}
  • types re-exports, among others, many heapless and littlefs2 types

At the same time, we have many modules that only contain one or two public types. For example, error only contains Error and Result. store::certstore only contains Certstore and ClientCertstore. While it makes sense to group the implementation into a module, it does not make sense to use trussed::error::Error, trussed::store::certstore::Certstore or trussed::platform::Platform to refer to these types.

I propose the following guidelines for cleaning up imports and modules:

  1. Types defined in public Trussed modules are not re-exported at all. Types from private Trussed modules are only re-exported once, from their parent module.
  2. Modules that only contain a few public types and that are not behind a feature gate are made private and types are re-exported in the parent module.

The goal of these changes would be to improve readability of the Trussed code and of the code using Trussed, to make it easier to import the correct types and to avoid surprising or unexpected imports.

I’m not sure how to deal with re-exports of external types. One option would be to only re-export them in a single location, types, or to have a re-export of the entire crate on the top-level and not re-export individual types.

What do you think?

robin-nitrokey avatar Mar 26 '24 15:03 robin-nitrokey