[Discussion/Question]: How to deal with indirect dependencies that are not on CRAN

[averissimo]

What is your question?

Example

Context:

• pkg.a depends on pkg.b but not on pkg.c.
• pkg.c is not defined on DESCRIPTION file of pkg.a
• pkg.c is only released on GitHub / R-Universe

For an actual case, pkg.a is teal.modules.clinical, pkg.b is teal.slice and pkg.c is teal.data

Outcome

• ❌ Check fails as it cannot find an install candidate for pkg.c

Solutions

1. Add entry for Config/Needs/verdepcheck of pkg.a to serve as hint on where to find pkg.c
   • Right now it discards any entry that is not on Depends/Imports/Suggests
   • We could use optional flag to enable this behavior
2. Re-add Remotes section to insightsengineering packages
   • Needs research how to mitigate issue with R-Universe
3. Wait until pkg.c is released on CRAN
   • teal.data should be released in next few months

Code of Conduct

• I agree to follow this project's Code of Conduct.

Contribution Guidelines

• I agree to follow this project's Contribution Guidelines.

[averissimo]

(moving discussion from chat to issue @pawelru)

I've already tested a solution of 1.: That would create some clutter.

However, there's a positive side-effect as it would make the max strategy more effective, as it would use pkg.c/teal.data development version.

[pawelru]

I personally leaning towards 2. This would be a clean solution because something wrong is with pkg.b hence any fixes needs to be done there.

I have some bad feeling about 1 as this would break encapsulation. I don't want people to specify all indirect deps there. On the other hand, we can change the behaviour in a way that the entry will be used on a match with any (!) of all (!) dependencies (currently it is used on a match with direct dependencies only). I see the value (not to mention max strategy as you pointed out) but this is quite a messy logic to be honest. If done, this needs to be very well documented.