Version constraints ignored when subpackage has no version constraints

[lunfel]

I have created a test package to test Jetpack and so far I found out that it does not always resolve dependencies properly. I am not sure if this issue should be reported to packrat repository instead?

If I create the following description file, it will install the exact version of the data.table package which is not the latest version. This works properly.

DESCRIPTION file
[...]
Imports:
    data.table (== 1.8.10)

If I then update the DESCRIPTION file as follow, I delete the .lock file and then run jetpack install, it will upgrade data.table to 1.12.8 which is the latest version at the time of writing this issue. Rio will also default to latest release because there are no constraints specified.

DESCRIPTION file
[...]
Imports:
    data.table (== 1.8.10),
    rio

So what I think is happening here is that the rio package has the following DESCRIPTION file for its latest version.

[...]
Imports: tools, stats, utils, foreign, haven (>= 1.1.0), curl (>= 0.6),
    data.table (>= 1.9.8), readxl (>= 0.1.1), openxlsx, tibble

It is overriding my original package constraints to fulfill descending constraints instead of falling back to previous version of rio to try and find a version compatible with data.table 1.8.10.

Resolving this by hand, I would look back in each version of rio available from latest to earliest and try to find a matching dependency. I have found that rio@0.2 would be matching as it does not specify any constraints on data.table version.

TL;DR

I would expect that

DESCRIPTION file
[...]
Imports:
    data.table (== 1.8.10),
    rio

resolves to

data.table@1.8.10
rio@0.2

But it instead resolves to

data.table@1.12.8
rio@0.5.16

Which does not respect my initial constraint of data.table (== 1.8.10),

[ankane]

Hey @lunfel, unfortunately, Jetpack doesn't perform dependency resolution yet (as remotes/devtools doesn't support it, and Packrat only provides a virtual environment). I'm hoping to integrate pkgdepends when it's further along.

[ankane]

This is captured in #1, so closing out