Prepare for big computational requirements

[llrs-roche]

A package is submitted to CRAN (pkgA), it has >100 first order of reverse dependencies

DESCRIPTION

Package: pkgB
Imports: pkgA

Repository should show the companies if dependencies (pkgB) fail with the new version of the package (pkgA).

With large number of packages depending on the one updated (pkgA) this can require lots of time above what is freely available on CRAN.

The CI must be prepared to deal with dependencies, update reports and prepare the images and software used to validate the packages.

[yannfeat]

Thanks for raising this!

Repository should show the companies if dependencies (pkgB) fail with the new version of the package (pkgA).

Could we please define "fail"? Does it mean that certain quality metrics thresholds are no longer met? Or that the namespace of that dependency now conflicts with the namespaces of other dependencies?

Before we dive into solutions, could we first define what “fail” means for a dependency in this context? Does it mean that the thresholds of certain risk assessment metrics are no longer met? Or, for example, does it refer to tests no longer passing, or namespace conflicts introduced by the updated dependency?

I also suppose that such a feature should be made available in val.pipeline, not just in our GitHub-hosted repo.

Once we agree on what constitutes a failure, we can break this down into steps, such as the following:

1. Confirm the scope of checks (compatibility, tests, risk assessment metrics, namespace integrity).
2. Decide how to automate reverse dependency detection and testing.
3. Plan reporting so companies (and perhaps maintainers as well) know exactly why a dependency failed, whether it is due to broken tests, conflicts, or unmet risk metric thresholds.
4. Consider resource constraints for running these checks across 100+ packages and how to optimize (parallel runs, caching).
5. Define what happens when failures occur: block the update, notify companies, provide downgrade instructions...

Happy to help outline these tasks further.

[llrs]

When I wrote it I had in mind failing R CMD check (--as-cran) on CRAN if it is an external package.
But you raise good questions, specially the last one regarding introducing namespace conflicts. This would require a bigger check that could be done using diffify if it ever gets a public API.