feat: add RFD describing support for multi-repo target

[j-lanson]

Resolves #962 .

Currently a very rough draft, perhaps too vague to be an RFD as-is. I'm looking for feedback from people who know the target resolution, salsa, and Session subsystems, then I can iterate on the content.

(EDIT from Andrew: Rendered)

[alilleybrinker]

Regarding the ref flag and multi-target seeds, we could add support for the single-target "VCS URL" spec from PyPI: https://pip.pypa.io/en/stable/topics/vcs-support/

Then, when resolving targets from a multi-target seed, any that point directly to Git URLs could be resolved to git+ VCS URLs, including with a ref specifier if necessary. This would permit ref handling in the multi-target case, and is probably what we'd need to do to support things like a Cargo.toml with Git-dependencies anyway. Similarly, I know Go dependencies are basically Git repos, so we'd also need to do this for future go.mod support.

[alilleybrinker]

We probably would also want to produce reports as we run.

[alilleybrinker]

Okay, remembering more of what I meant by the comment above. I think this section should have one more paragraph added explaining that when we're executing analyses in parallel we should be printing reports as they're finished. This avoids holding reports in memory and means we provide a more responsive user experience.

[j-lanson]

I'd presume for multi-target we'd want to offer some kind of "summary" printing option? and/or print the full report as JSON to a target folder?

[mchernicoff]

Adding the option to print a JSON report to a target folder, even for a single target run, is something I brought up in one of the discussions last week. At least one Hipcheck user is going that already as part of a pipeline that includes Hipcheck. They do it now by piping the JSON output from stdout to a file, but we could make a flag to handle that ourselves. Happy to make an issue for that if we think it's a good idea.

[alilleybrinker]

Left some thoughts. Happy to discuss further.

[alilleybrinker]

Okay, remembering more of what I meant by the comment above. I think this section should have one more paragraph added explaining that when we're executing analyses in parallel we should be printing reports as they're finished. This avoids holding reports in memory and means we provide a more responsive user experience.