Dependency filters for production

[wlandau]

@shikokuchuo, this PR flags packages whose upstream dependencies have issues. There is a new issues_dependencies() function called from record_versions(), and it works like this. As an example, let's take our mirai/crew ecosystem and add a package x with dependencies nanonext and mirai and reverse dependency crew.aws.batch:

If mirai has a check error, then issues_dependencies() flags everything that depends on it. Specifically, it returns a nested list:

list(
  crew = list(mirai = character(0L)),
  x = list(mirai = character(0L)),
  crew.aws.batch = list(mirai = c("crew", "x")),
  crew.cluster = list(mirai = "crew")
)

The list says:

1. Packages crew, x, crew.aws.batch, and crew.cluster cannot stay in production because of the issue with mirai.
2. The upstream package at the root of the problem is mirai.
3. mirai impacts crew.aws.batch via packages crew and x.
4. mirai impacts crew.cluster via package crew.

A downstream package can be impacted by more than one upstream one. For example, if both mirai and crew directly cause issues in some way, then issues_dependencies(packages = c("mirai", "crew"), ...) returns:

list(
  crew = list(mirai = character(0)),
  x = list(mirai = character(0)), 
  crew.aws.batch = list(
    mirai = c("crew", "x"),
    crew = character(0)
  ), 
  crew.cluster = list(
    mirai = "crew",
    crew = character(0)
  )
)

This choice of output format may seem complicated, but we can have downstream code interpret it (e.g. the RSS feed) and explain to the user that e.g. "there is an issue in package A which impacts your package B through strong direct dependencies C and D".

Also in this PR: wherever an issue is flagged in a package for any reason, the JSON file includes the version and remote SHA of the problematic release.

Lastly, an FYI: issues_dependencies() computes on a large dependency graph, and igraph is the best tool for the job. Unfortunately, it is quite a heavy dependency for multiverse.internals.

[shikokuchuo]

I have a couple of updates to the tests, but it seems I can't push to the branch on your fork. I think we can probably branch off the repo directly in future.

[wlandau]

Hmm... looks like your fork is at version 0.1.4, which is from 2 weeks ago: shikokuchuo@1c58a2a. I only see the main branch. What updates do you have for the tests? Would it be easy to re-implement?

[wlandau]

Oh, you meant on my fork. Yeah, branching off the main repo would let us edit each other's PRs.

[shikokuchuo]

what i mean is I've pulled this PR using the GH client. in the past it's let me push edits directly to the PR, but I think as this is on your fork it doesn't let me. Unless I'm not doing it correctly...

[shikokuchuo]

Nothing major I was really just re-verifying the mock data vs. the real pulled data

[shikokuchuo]

Just one suggestion. I can add my minor test updates later.

[shikokuchuo]

Just so I can understand it fully, if we add later to this dependency graph as upstream of nanonext, and it has a check error, what would issues_dependencies() return? Can we mock that in your test repo?

[shikokuchuo]

Thanks! Just pending my question on what it looks like when the dependency graph is deeper than 3 nodes.
EDIT: I'm just adding crew to R-Multiverse to check . Hope you don't mind!

[wlandau]

FYI I just did some profiling and pushed optimizations. Now, issues_dependencies(meta$package, meta) only takes 111.3 seconds on my machine, where meta is the output of meta_packages(repo = "https://cran.r-universe.dev"). In other words, it takes under 2 minutes to check all of CRAN in the case when every CRAN package has an issue. issues_dependencies("crew.aws.batch", meta) takes only 0.266 seconds (creating the dependency graph is now fast).

[shikokuchuo]

Thanks. I now have the mental model for this. Looks good.

Can I suggest that you set the 'verbose' default to FALSE? Once the repo gets larger I think it will be too verbose to have this stuff in the log files.

[wlandau]

Just so I can understand it fully, if we add later to this dependency graph as upstream of nanonext, and it has a check error, what would issues_dependencies() return? Can we mock that in your test repo?

Here's what the graph looks like:

And supposing there is an issue in later, issues_dependencies("later", meta) returns:

list(
  nanonext = list(later = character(0)),
  mirai = list(later = "nanonext"),
  crew = list(later = c("mirai", "nanonext")),
  crew.aws.batch = list(later = "crew"), 
  crew.cluster = list(later = "crew"),
)

Interpretation:

• later causes an issue that cascades downstream to packages nanonext, mirai, crew, crew.aws.batch, and crew.cluster through the dependency graph.
• nanonext directly depends on later through its DESCRIPTION file.
• mirai indirectly depends on later through nanonext, and nanonext is a strong direct dependency.
• crew indirectly depends on later through strong direct dependencies mirai and nanonext.
• crew.aws.batch indirectly depends on later through strong direct dependency crew.
• crew.cluster indirectly depends on later through strong direct dependency crew.

[wlandau]

Can I suggest that you set the 'verbose' default to FALSE? Once the repo gets larger I think it will be too verbose to have this stuff in the log files.

Done in e41b66d, though we may need it for log files if we notice too much slowness for some reason.