checkout() breaks restoring if checking out older snapshots

[gowerc]

When using checkout(<repo>) it sets the repository URL in the lockdown file to be the value of <repo> without checking wether the current version of renv can be installed from it or not. This causes issues because checkout() also doesn't appear to downgrade renv to a version that is available in <repo>

As an example:

• Initiate renv using 1.0.7 (published Apr 11, 2024 10:20 PM UTC).
• Install a couple of packages (doesn't matter what)
• Use checkout("https://packagemanager.posit.co/cran/2024-01-02") to fix my packages to a historic date

If you then inspect the lock file you will see:

"Repositories": [
      {
        "Name": "CRAN",
        "URL": "https://packagemanager.posit.co/cran/2024-01-02"
      }
    ]

However renv 1.0.7 isn't available from this repo but checkout() has left renv untouched.
This then means that if someone else clones the project and attempts to load R they are greeted with the following error message as renv is unable to bootstrap itself:

# Bootstrapping renv 1.0.7 ---------------------------------------------------
- Downloading renv ... FAILED
Error in h(simpleError(msg, call)) : failed to download:
All download methods failed

The use case of downgrade may appear counter intuitive but we see it happen at our company where quite often people may start a project with full CRAN only later to decide that they need to use "validated packages" and thus use checkout() to set their repo to be a "validated PPM" bucket

[kevinushey]

Thanks for the bug report! In this scenario, would you rather have renv itself also be downgraded, or would you prefer if the latest-available version of renv were installed from some alternate source?

[gowerc]

Yer, after submitting the report I was pondering this and I'm not actually sure. My gut is saying that I think you'd want to retain the original repo for renv to keep the version however you wouldn't want that repo to be used for anything other sourcing renv. Let me double check / share with some colleagues and see what they think.

[kieranjmartin]

I would think that my expected behaviour would be to get "old" renv: I think checkout should ideally make my lock file reflect exactly a specific snapshot.

That said, there is a little weirdness here; I could checkout a snapshot with an renv <1, which does not have the checkout function in it. I think this is still appropriate.

[gowerc]

@kevinushey - I saw that you went for the approach I mentioned of reverting renv itself. If I get some time later today / next week I'll try and do some tests but my immediate fear would be wether this has the potential to cause conflicts with having and old package with future versions of activate.R and the other support stuff. I am wondering if downgrading needs to be combined with re-init'ing ? Apologies if this is already a solved problem I am not too familiar with the internals of renv.

[kevinushey]

You're right -- we'll definitely want to re-generate the activate script with the newly-installed version of renv. I'll add that in.