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

averissimo commented 11 months ago

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

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
Re-add Remotes section to insightsengineering packages
- Needs research how to mitigate issue with R-Universe
Wait until pkg.c is released on CRAN
- teal.data should be released in next few months

Code of Conduct

[X] I agree to follow this project's Code of Conduct.

Contribution Guidelines

[X] I agree to follow this project's Contribution Guidelines.

averissimo commented 11 months ago

(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 commented 11 months ago

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.

insightsengineering / verdepcheck