(chore) Crate re-haul investigation (naming, combining, publish ready-ness)

[gmulhearn]

In anticipation of publishing to crates.io, we should rename our crates to names that will be clearly understood on crates.io, and are namespaced properly.

Current crate set:

Aries

• aries/aries_vcx,
• aries/messages_macros,
• aries/messages,
• aries/misc/shared,
• aries/misc/legacy/diddoc_legacy,
• aries/agents/mediator,
• aries/agents/mediator/client-tui,
• aries/agents/aries-vcx-agent,
• aries/agents/aath-backchannel,
• aries/wrappers/uniffi-aries-vcx/core,
• aries/aries_vcx_anoncreds,
• aries/aries_vcx_wallet,
• aries/aries_vcx_ledger,
• aries/misc/indy_ledger_response_parser,
• aries/misc/test_utils,

DID

DID-Core

• did_core/did_doc,
• did_core/did_parser_nom,
• did_core/public_key,
• did_core/did_resolver,
• did_core/did_resolver_registry,

CONSIDERATION: can these be combined:

• consider dependencies and if we are burdening consumers be combining

Methods

• did_core/did_methods/did_peer,
• did_core/did_methods/did_key,
• did_core/did_methods/did_resolver_sov,
• did_core/did_methods/did_resolver_web,
• did_core/did_methods/did_jwk,
• did_core/did_methods/did_cheqd,
• did_core/did_methods/did_cheqd/cheqd_proto_gen (VCX development util crate, don't publish)

Other

• misc/simple_message_relay,
• misc/display_as_json,

Proposed crate set:

General Question

This is a general question that applies to all of these proposals: should we use underscores (crate_name), or hyphens (crate-name). Here's some stats: https://users.rust-lang.org/t/crate-io-statistics-for-hyphen-vs-underscore-package-names/120604 hyphens are much more popular..

DID

DID-Core

Combination Proposal

I propose we combine these 3 crates:

• did_core/did_doc,
• did_core/did_resolver,
• did_core/did_resolver_registry

into a single crate named:

• did_core (or did-core)

why?

The current chain of dependencies amongst these 3 is did_resolver_registry depends on did_resolver depends on did_doc. So some questions to consider are:

1. is it bad for did_resolver consumers to bring in the did_resolver_registry code/dependencies?

IMO, no, as did_resolver_registry is extremely lightweight, and doesn't include any dependencies that did_resolver doesn't already include - it's just a nice utility.

2. is it bad for did_doc consumers to bring in the did_resolver code/dependencies?

IMO, also no, the same reasons above apply ^. Additionally, combining them would be nice, as then DID Core types & concepts (resolver interface) are in 1 place.

ALSO, there is already a crate published called did_doc. There is a crate called xdid-core: https://crates.io/crates/xdid-core, but perhaps its fine for us to try grab the did_core crate name?

Everything else

I propose we keep the other did core crates seperate and rename them as so:

• did_core/did_parser_nom, rename: did or did_parser. - i think we can remove the nom implementation detail. We aren't actually exposing any nom functionality out of this crate, so the fact that it uses nom is just an internal detail.
• did_core/public_key, rename: vcx_public_key - i think we should prefix this, as public_key is just too vague. Also note that this is beyond the domain of "did_core", this is more of a lightweight utility crate that we just all around the codebase.

Methods

Option 1 (no namespacing):

• did_core/did_methods/did_peer -> did_peer (note there is already a crate called did-peer)
• did_core/did_methods/did_key -> did_key (note there is already a DIF crate called did-key)
• did_core/did_methods/did_resolver_sov -> did_sov (drop the "_resolver" for consistency (even though it's just a resolver ATM))
• did_core/did_methods/did_resolver_web -> did_web (drop the _resolver, note there is already a crate called did-web)
• did_core/did_methods/did_jwk -> did_jwk (note there is already a crate called did-jwk)
• did_core/did_methods/did_cheqd -> did_cheqd

Unfortunately, since most of these names are already taken in the hyphen form, we won't be able to publish (even if we underscore instead: https://internals.rust-lang.org/t/pre-rfc-unify-dashes-and-underscores-on-crates-io/13216). So we must consider other options

Option 2 (vcx_ namespace):

• vcx_did_peer
• vcx_did_key
• vcx_did_sov
• vcx_did_web
• vcx_did_jwk
• vcx_did_cheqd

Related question: if we do this, would we want to namespace the proposed did_core crate as vcx_did_core as well, to make it obvious they are all from the same family? e.g. "vcx_did_key is the implementation of did-key method which uses vcx_did_core components"

Publishing Issues

Publishing util crates?

Note that crates.io will not let us publish anything with path only dependencies (i.e. every dependency must also be published to crates.io) - this can cause us grief with our various utility crate dependencies

• One utility crate which we use everywhere, is display_as_json. It's extremely lightweight, it just derives Display to string the JSON string of the type it's derived on. In this case, rather than publishing display_as_json, i'd suggest we migrate to something like https://crates.io/crates/display_json , which does the same thing, but is maintained externally