manage_deps() doesn't respect pinned version

[andrewGhazi]

Hi there, I maintain a new module in the Carpentries incubator. I used sandpaper::pin_version("[email protected]") in an attempt to pin the dependency on duckdb to version 1.1.2. You can see the updated renv.lock file here. The build process that gets triggered shows the dependency on the right version but then ignores that and tries to install the latest bugged version when setting up the cache to build the site, causing the whole build to fail. The subsequent re-attempts also fail from the same issue.

I believe the offending sandpaper::manage_deps() call in the github workflow is this line. I've tried to understand the source code for both the github action and sandpaper::manage_deps() but there's just too many layers of abstraction for me to identify the source of the error.

Sidenote: The failure from duckdb has something to do with a cleanup script in the latest version of duckdb which is why I'm trying to pin to 1.1.2.

[froggleston]

Hi @andrewGhazi - I'm currently on holiday, and not very knowledgeable in the internals and intricacies of renv, but I'm wondering if it's down to a dependent package pulling in a newer version?

e.g. CuratedAtlasQueryR also depends on duckdb, so I don't know if manage_deps() takes the pin into account if another package also pulls in a newer version...

[andrewGhazi]

That seems plausible, but it seems like there must be a way to solve it. It's a pretty frustrating situation because I had thought the entire purpose of all this renv/CI/build infrastructure was to be able to set specific dependency versions.

[froggleston]

I agree - I'll be able to take a look at this in the new year most likely, but I'll probably need some community assistance as renv isn't my strong suit.