Should the monorepo layout have a spec

[xla]

Posing this as a question, to gauge if there might be value in speccing the layout of the monorepo. It being motivated by a lot of string manipulation up and down the stack, including library consumers. It also being the source of a confusion and often times bugs stemming from misunderstanding of the correct path into the namespaces and refs.

An alternative would be that downstream consumers never are exposed to any of it, likely related to #346

Beyond the public API of the library it should be considered if the monorepo layout is significant across implementations and therefore needs formalisation.

Ref. #368

[kim]

speccing the layout of the monorepo

The layout was conceived in RFC: Identity Resolution. It needs to be brought up to date in some details, and moved into the docs/spec section.

string manipulation up and down the stack, including library consumers

Can you substantiate that? The remote helper was created to hide the layout from users, so if there is any refspec manipulation upstream, it is in the wrong place.

[FintanH]

One thing that I often run into is that when trying to specify a ref for browsing that lives under a remote. Because there's the prefixing of heads/ we get end up having to plug that in. See this issue I created https://github.com/radicle-dev/radicle-upstream/issues/1043

[kim]

I guess we could consider wrapping surf again, and use a shared set of types instead of stringly refspecs

[FintanH]

I guess we could consider wrapping surf again, and use a shared set of types instead of stringly refspecs

How would we feel about having a separated package for our git stuffz that radicle-link and radicle-surf could depend on? :eyes:

[xla]

How would we feel about having a separated package for our git stuffz that radicle-link and radicle-surf could depend on? eyes

radicle-stringly <- push to npm

[kim]

Definition of git stuffz?

[FintanH]

I think the git::ext::* and git::types::* stuffz could be quite useful in radicle-surf as well. Basically, anything that isn't specific to radicle-link :)

[kim]

Ya, except git::types::* is very much specific to link