We've realized today that, although tor-rtcompat is an important piece of our public API, we do not currently plan to declare it 1.0. That is, we need to make sure that we can continue to improve its feature set even as we keep arti_client stable.
To do this, we plan to make the traits in tor-rtcompat sealed by default for now, with an optional unseal-traits feature to unseal them.
@Diziet, do you think that we should also re-export the relevant runtimes from arti_client, so that users don't also need to depend directly on the tor-rtcompat crate?
This is quite vexing, actually. tor-rtcompat conditionally exports many things. I doubt we want to recapitulate that in terms of our own cargo features.
We could have tor-rtcompat have a module full of things that arti-client could *-reexport, but absent that I think the way we have it here is OK. TorClient::builder() gets you PreferredRuntime so you may not ever need to name the runtime.
Having slept on this, and thought about it some more: I'm not now convinced that this (and !712 (closed)) is the right direction.
Here is an alternative approach:
tor-rtcompat traits remain unsealed. Extending the traits is a major version bump. We expect that this will happen occasionally. (We could signal this with a 0.x version number.)
Most users ought not to need to import tor-rtcompat. We already don't re-export the traits, so arti-client doesn't need a semver bump when we amend tor-rtcompat traits since any implementor (or caller of trait methods) must be able to name the trait.
Right now, too many users need to import tor-rtcompat to obtain the type names of the Runtimes (and in some cases the constructors). Those type names can be re-exported by arti-client (as per #564 (comment 2832873)) with minimal semver implications. We should provide an arti_client::runtime module for this.
The overall result will be that imlementors of tor-rtcompat traits, and callers of those methods, will get semver management of changes to those traits, but everyone else can remain in blissful ignorance.
How do we handle this for Arti 1.0? I still think it is too late to add the new runtime module. I suggest: