Cargo design doc

[brunoapimentel]

A design doc for implementing Cargo support. It mostly follows the general principle for other package managers. The bigger issue of having Rust-based dependencies is described in an appendix since this is not strictly Rust support.

Corresponding repository for ITs is https://github.com/cachito-testing/cachi2-rust

Maintainers will complete the following section

• Commit messages are descriptive enough
• Code coverage from testing does not decrease and new code is covered
• Docs updated (if applicable)
• Docs links in the code are still valid (if docs were updated)

[eskultety]

it'll be a while before I get to read/understand/review this, but kudos for pushing the "PR for designs" way. Feels like it's going to be more ergonomic + we can not only close the PR, but also retain the doc for future reference, OR convert it to docs, i.e. it gives us a bit more flexibility.

[slimreaper35]

Is this ready for review ?

[a-ovchinnikov]

Is this ready for review ?

All major parts are there, I will still be tweaking the document a little, but yes, it is ready for review/suggestions.

[brunoapimentel]

Now that we have ADRs in the repo, I wonder what approach we should take with these design docs. Should they just become ADRs? I feel like they're too big for an ADR, but the info here is important. Wdyt?

[slimreaper35]

To identify them and mark them as such in the SBOM, we'd
need only to check all the times a single package appears as a transitive
dependency in this output.

I am not sure if I understand this section. It looks like the same approach as for yarn classic.

[a-ovchinnikov]

Yes, it essentially is.

[slimreaper35]

The path for the document is slightly incorrect.
s/docs/designs/cargo-support.md/docs/design/cargo.md (in case this ends up being a design document)

[a-ovchinnikov]

Now that we have ADRs in the repo, I wonder what approach we should take with these design docs. Should they just become ADRs? I feel like they're too big for an ADR, but the info here is important. Wdyt?

I think keeping them in design directory is fine. I am not sure if formalizing them more would actually help -- there are not too many decisions and designs to require them to strictly follow the same pattern (and there is no set rule for a pattern anyway).