I'm kind of imagining a rule `fetch_single_coordin...
# development
I'm kind of imagining a rule
fetch_single_coordinate(coord: MavenCoord) -> Digest
, except I just tell the engine to act as though that rule has executed and give it both the input and the output
Using REAPI’s notion of an Action: In the context of “batching” test runs, I’ve thought about “synthetic Actions” where you would run
in a single process execution to execute a batch of tests all at once and then unpack the Action->ActionResult resulting from that process execution by creating N synthetic Action->ActionResult mappings for each test. You would do that by creating a synthetic command-line for the fake process executions. It would match how Pants would setup a run of a single test. Then later if Pants tried to execute a single test, by constructing the command-line for a single test, it would see that the single test already ran even though it was run in a single batch run of
There is probably a more generic formulation of this idea that doesn’t rely on creating synthetic process executions. But it does point to a limitation in the engine that applies as much to test batching as it does to the jar resolution on which you are working. I.e., how to assert individual facts from a “batch” run that can also assert those facts in bulk.
Interesting, yeah. I don't think this would work for testing, but for external dependency resolution I could also imagine taking a full index of the remote repo as a prior input. Then even with relatively frequent cache invalidation, you could at least be sure that your resolution and fetching actions are operating effectively in-memory, and even "inefficient" fetches aren't actually touching the network
It kind of suggests that where possible, the resolving tool shouldn't be doing the big network fetches, instead the engine should be taking that over so it can intelligently cache simple URL+digest ->
Yes 100%, I think this wants to be deconstructed into "resolve to versions" as one process and "fetch a version" as another
Where the "fetch" should probably be a single DownloadFile intrinsic per file
(Ideally supplying a sha256 in each)