Fix R functional test failures on Windows ARM runners

[zackverham]

Intent

When a CRAN-like package's installed version (from a binary repo like P3M/RSPM) is newer than what available.packages(type="source") returns, the isDevVersion check was incorrectly blanking out Source and Repository, triggering renvPackageSourceMissing. This is a false positive — the package came from a known repository; the version difference is just binary-vs-source repo timing.

Remove the isDevVersion branch for CRAN-like packages so their lockfile repository info is always preserved. Also remove the now-unused isDevVersion, findAvailableVersion, and package_version functions.

Type of Change

• • Bug Fix
• • New Feature
• • Breaking Change
• • Documentation
• • Refactor
• • Tooling

Approach

User Impact

Automated Tests

Directions for Reviewers

Checklist

• I have updated the root CHANGELOG.md to cover notable changes.

[zackverham]

Code review

No issues found. Checked for bugs and CLAUDE.md compliance.

🤖 Generated with Claude Code

_{- If this code review was useful, please react with 👍. Otherwise, react with 👎.}

[jonkeane]

I might be missing some context, but

This happens on binary-only repos (e.g. P3M/RSPM on Windows ARM) where the binary version leads the source version.

This sounds like something else is wrong, either with the P3M repo or our configuration of repos when we make this call. For the R / CRAN-like ecosystem I don't think there should ever be a circumstance where there is a binary available but the source isn't (or is older than the binary). Could you explain a little more about what's going on here?

[zackverham]

This is the issue - cran for whatever reason is proving the wrong version for windows

[jonkeane]

Ah ah ah maybe I misread "the binary version leads the source version." then? That screenshot the other way around from what I thought you were describing: the binary is an earlier number than the source. That is totally possible and common. And whatever the publisher does with that should be robust: where the version is recorded (and the repo + other details), such that when it's pulled on connect connect will find the right thing (ideally from a binary if it's available, but will fall back to source if that's not).

In this case: maybe our test harness is too strict in requiring a specific number baked into the lockfile (or elsewhere, I haven't dug on these tests recently). But I would hope that we could have this test run such that so long as some renv was installed it doesn't matter too much if it's 1.1.8 or 1.1.7

[zackverham]

The binary mismatch I think is coming from what we get from P3M - which on the windows github runners is coming through as 1.1.8. I haven't done the deep dive to identify where the mismatch is precisely - I was running these experiments in the background, hoping cran would resolve things within a day or so.

[zackverham]

i.e.

[karawoo]

Looking more closely at the logs, something seems off here about the failures. For one thing, it's only failing on one of the two windows runners. If the issue were the lack of windows binaries for 1.1.8 I'd expect to see the failure for both.

Also, earlier in the logs of the failing run you can see that we do successfully install 1.1.8 from source (since the binary isn't available):

I had assumed the issue was that renv was requesting a specific binary version (1.1.8) that wasn't available for windows, but I should have looked closer at what is actually installed, because we do successfully build 1.1.8 from source.

Something appears to be happening later where available.packages(type = "source") is not returning the expected result, but it's happening only on this windows runner and not the other. I wonder if we could add some logging to get a better sense of what is being returned here from available.packages()? And maybe what repositories we're checking when we run that?

[karawoo]

Here's another difference between the failing windows runner and the successful one -- the failing one fails to set up CRAN and P3M mirrors

We might try adding a step to the CI workflow to explicitly configure the CRAN repo and see if that helps

 - name: Configure CRAN mirror
   run: |
     Rscript -e "cat('options(repos = c(CRAN = \"https://cloud.r-project.org\"))\n', file = file.path(Sys.getenv('R_HOME'), 'etc', 'Rprofile.site'), append = TRUE)"