Renv packages installation order

[albi]

Hi,

I am using renv to keep track of the packages used in my project, the problem is that one of the packages I need (InSituType) does not declare a dependency. I added the undeclared dependency to the renv.lock file with renv::record("lsa")but when the project CI runs renv::restore() it tries to install InSituType before lsa and fails.

Is there a way to specify the order in which the packages should be installed by renv? Or, what is the recommended way of solving problems like this one?

Thank you!

[edavidaja]

I think this issue may be relevant. You could try enabling the pak installation backend and seeing if that helps.

Alternatively, if the project is open to accepting contributions, you could try to get a fix in upstream.

[albi]

Hi @edavidaja, thank you very much for your answer. Unfortunately I could not find any useful information in the linked GitHub issue. I also enabled the option to use pak in renv but it seems like pak is not yet used by renv::restore().

I reported the issue to the developers of InSituType and they acknowledged it, but they did not give me any estimate for when they will fix it.

[kevinushey]

Are you able to alter how renv::restore() is invoked on CI? If so, then you could try performing two separate restores, e.g.

renv::restore(packages = "lsa")
renv::restore()

Note that any packages installed from the first restore would be re-used on the second restore.

[albi]

@kevinushey thank you very much for your suggestion! I modified my CI as follow:

jobs:
  build-deploy:
    runs-on: ubuntu-latest
    permissions:
      contents: write
    steps:
      - name: Check out repository
        uses: actions/checkout@v4

      - name: Set up Quarto
        uses: quarto-dev/quarto-actions/setup@v2

      - name: Install R
        uses: r-lib/actions/setup-r@v2
        with:
          r-version: '4.4.0'

      - name: Run Bash commands
        run: |
          if (!requireNamespace("renv", quietly=TRUE)) install.packages("renv")
          renv::restore(packages = "lsa")
        shell: Rscript {0}

      - name: Install R Dependencies
        uses: r-lib/actions/setup-renv@v2
        with:
          cache-version: 1

      - name: Render and Publish
        uses: quarto-dev/quarto-actions/publish@v2
        with:
          target: gh-pages
        env:
          GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}

But unfortunately it does not work, renv does not install lsa:

Run if (!requireNamespace("renv", quietly=TRUE)) install.packages("renv")
  if (!requireNamespace("renv", quietly=TRUE)) install.packages("renv")
  renv::restore(packages = "lsa")
  shell: /usr/local/bin/Rscript {0}
  env:
    BUNDLE_EXT: linux-amd64.deb
    R_LIBS_USER: /home/runner/work/_temp/Library
    TZ: UTC
    _R_CHECK_SYSTEM_CLOCK_: FALSE
    NOT_CRAN: true
# Bootstrapping renv 1.0.7 ---------------------------------------------------
- Downloading renv ... OK
- Installing renv  ... OK
- One or more packages recorded in the lockfile are not installed.
- Use `renv::status()` for more details.
'getOption("repos")' replaces Bioconductor standard repositories, see
'help("repositories", package = "BiocManager")' for details.
Replacement repositories:
    BioCsoft: https://bioconductor.org/packages/3.19/bioc
    BioCann: https://bioconductor.org/packages/3.19/data/annotation
    BioCexp: https://bioconductor.org/packages/3.19/data/experiment
    BioCworkflows: https://bioconductor.org/packages/3.19/workflows
    BioCbooks: https://bioconductor.org/packages/3.19/books
    CRAN: https://packagemanager.posit.co/cran/__linux__/jammy/latest
- The library is already synchronized with the lockfile.

[kevinushey]

That's surprising to me... are you able to share the lockfile you're using? For what it's worth, I see the same thing If I run this in a "fresh" renv project:

> renv::restore(packages = "lsa")
- The library is already synchronized with the lockfile.

That is, this could imply that the lockfile does not contain a reference to the lsa package, but IIRC you did explicitly add it earlier. Is it possible it was removed as part of a later snapshot() call?