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]

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).

[eskultety]

This is an amazing write-up! I skipped the Python related parts since I don't think those parts are heavily dependent on which approach for prefetching we end up selecting, so I'd probably prefer to save that information for a different doc/ADR and make this one leaner.
I raised a few questions to help me better understand the background.

[eskultety]

I wonder if these Python related appendices should be part of this design doc/ADR in order to be merged. I perceive that work to be logically connected, but not imperative to deliver the functionality for what is discussed here.

[a-ovchinnikov]

Yes, this is only tangentially related to Rust support, so there is a good argument for dropping it. However to the best of my knowledge the original request was more about supporting Rust extensions to Python than just supporting Rust itself, so I think it is ok to keep it as an Appendix.

[eskultety]

the original request was more about supporting Rust extensions to Python than just supporting Rust itself

That is true, however, this work is the initial step towards resolving that

, so I think it is ok to keep it as an Appendix.

On one hand I don't want to lose the information because it needs to be added to the follow up work, on the other hand though these appendices just bloat the document with only tangentially related information. What's the plan for adding a design doc on the follow up work, will it contain duplicate information, will the information here in appendices be transferred over to the new document or will we just link it from the new docs? Again, I don't question the depth or quality of information provided, just the timeline and the expected outcome.

[a-ovchinnikov]

I think transferring the Appendices is the best approach: by being appendices to a design they will be preserved and also out of sight, then once we are ready to work on Python-Rust support we can move them out and put them into a separate document.

[a-ovchinnikov]

This is an amazing write-up!

I must point out that it is 95% @brunoapimentel's work that I have inherited.

[eskultety]

The strictly relevant parts LGTM. I have not invested time into reviewing the appendices.