Skip to content

Install citeproc instead of pandoc-citeproc when latter required #755

Open
Open
Install citeproc instead of pandoc-citeproc when latter required#755
Labels
bugan unexpected problem or unintended behavior

Description

@jamesmbaazam
jamesmbaazam
opened on Mar 13, 2025

Thank you for this really useful package.

We are having an issue where one of our hard dependencies requires pandoc-citeproc as a system dependency but it is superseded by citeproc, so our GitHub Actions fail intermittently. See an example. We have been discussing it in epiforecasts/EpiNow2#1035 and it seems one potential solution would be to fix it from your end.

Could you advise on this? Thanks.

Activity

  1. remlapmot commented on Mar 14, 2025

    @remlapmot
    remlapmot
    on Mar 14, 2025
    Contributor

    (I'm just a user)

    I also had this problem. The easiest quick fix for this is to switch that run to use an ubuntu-22.04 runner because pandoc-citeproc is still available in the Jammy archives but it's not in the Noble archives.

    What confuses me is why this error doesn't occur on the R release runs using ubuntu-latest (Noble), so maybe there is some pak/pkgdepends/sysreqs bug related to R devel??

    Interestingly PPPM does know about the difference in system requirements as does pak::sysreqs().

    https://packagemanager.posit.co/client/#/repos/all/packages/loo/overview?search=loo&distribution=ubuntu-24.04

    pak::pkg_sysreqs('loo', sysreqs_platform = "ubuntu-22.04")
#> 
#> ✔ Updated metadata database: 7.38 MB in 9 files.
#> 
#> ℹ Updating metadata database
#> ✔ Updating metadata database ... done
#> 
#> ── Install scripts ───────────────────────────────────────────── Ubuntu 22.04 ──
#> apt-get -y update
#> apt-get -y install pandoc-citeproc pandoc
#> 
#> ── Packages and their system dependencies ──────────────────────────────────────
#> loo – pandoc, pandoc-citeproc
pak::pkg_sysreqs('loo', sysreqs_platform = "ubuntu-24.04")
#> ── Install scripts ───────────────────────────────────────────── Ubuntu 24.04 ──
#> apt-get -y update
#> apt-get -y install pandoc
#> 
#> ── Packages and their system dependencies ──────────────────────────────────────
#> loo – pandoc

    Created on 2025-03-14 with reprex v2.1.1

  2. jamesmbaazam commented on Mar 14, 2025

    @jamesmbaazam
    jamesmbaazam
    on Mar 14, 2025
    Author

    @remlapmot Thanks so much for chipping in.

    We have other workflows that run on various latest Ubuntu releases. See for example the R CMD CHECK workflow runners in https://github.com/epiforecasts/EpiNow2/blob/main/.github/workflows/R-CMD-check.yaml#L36-L41.

  3. gaborcsardi commented on Mar 15, 2025

    @gaborcsardi
    gaborcsardi
    on Mar 15, 2025
    Member

    This is already fixed in https://github.com/rstudio/r-system-requirements/blob/main/rules/pandoc-citeproc.json#L10

            "packages": ["pandoc-citeproc"],
        "constraints": [
          {
            "os": "linux",
            "distribution": "ubuntu",
            "versions": ["14.04", "16.04", "18.04", "20.04", "22.04"]
          },

    ❯ pak::sysreqs_db_match("pandoc-citeproc", sysreqs_platform = "ubuntu-22.04")
[[1]]
# A data frame: 2 × 5
  spec            sysreq          packages  pre_install post_install
  <chr>           <chr>           <list>    <list>      <list>
1 pandoc-citeproc pandoc-citeproc <chr [1]> <NULL>      <NULL>
2 pandoc-citeproc pandoc          <chr [1]> <NULL>      <NULL>

    ❯ pak::sysreqs_db_match("pandoc-citeproc", sysreqs_platform = "ubuntu-24.04")
[[1]]
# A data frame: 1 × 5
  spec            sysreq packages  pre_install post_install
  <chr>           <chr>  <list>    <list>      <list>
1 pandoc-citeproc pandoc <chr [1]> <NULL>      <NULL>

    The problem is that pak failed to download the system requirements mapping in your workflow, so it used the mapping that come with the package and these are older:

      ! Failed to update system requirement mappings, will use cached mappings.

    https://github.com/epiforecasts/EpiNow2/actions/runs/13817915620/job/38655834925#step:5:211

    As a workaround you can set the PKG_SYSREQS_DB_UPDATE_TIMEOUT env var (cf. https://pak.r-lib.org/reference/pak-config.html) to a larger value than the current default which is 5 seconds.

  4. remlapmot commented on Mar 16, 2025

    @remlapmot
    remlapmot
    on Mar 16, 2025
    Contributor

    Oh brilliant - thanks.

  5. remlapmot commented on Mar 17, 2025

    @remlapmot
    remlapmot
    on Mar 17, 2025
    Contributor

    I got this to work using options() before my setup-r-dependencies step.

          - name: Set pak options
        shell: bash
        run: echo 'options(pkg.sysreqs_db_update_timeout = as.difftime(59, units = "secs"))' >> ~/.Rprofile

    However, when I tried to set this using the environment variable say PKG_SYSREQS_DB_UPDATE_TIMEOUT=30s pak and pkgdepends seem to fall over with the following error message:

    withr::local_envvar(PKG_SYSREQS_DB_UPDATE_TIMEOUT = "30s")
Sys.getenv("PKG_SYSREQS_DB_UPDATE_TIMEOUT")
#> [1] "30s"
pkgdepends::current_config()
#> Error in rec$env_decode(envv, envvname, env): unused argument (env)

    Created on 2025-03-17 with reprex v2.1.1

    And the same happens for PKG_METADATA_UPDATE_AFTER

    withr::local_envvar(PKG_METADATA_UPDATE_AFTER = "2h")
Sys.getenv("PKG_METADATA_UPDATE_AFTER")
#> [1] "2h"
pkgdepends::current_config()
#> Error in rec$env_decode(envv, envvname, env): unused argument (env)

    Created on 2025-03-17 with reprex v2.1.1

    Is it possible there's a bug in pkgdepends parsing these environment variables? Or maybe I have used the wrong syntax.

  6. gaborcsardi commented on Mar 17, 2025

    @gaborcsardi
    gaborcsardi
    on Mar 17, 2025
    Member

    withr::local_envvar(PKG_SYSREQS_DB_UPDATE_TIMEOUT = "30s")

    Try without the s suffix.

  7. remlapmot commented on Mar 17, 2025

    @remlapmot
    remlapmot
    on Mar 17, 2025
    Contributor

    Unfortunately, they both still seem to fail

    withr::local_envvar(PKG_SYSREQS_DB_UPDATE_TIMEOUT = 30)
Sys.getenv("PKG_SYSREQS_DB_UPDATE_TIMEOUT")
#> [1] "30"
pkgdepends::current_config()
#> Error in rec$env_decode(envv, envvname, env): unused argument (env)

    Created on 2025-03-17 with reprex v2.1.1

    withr::local_envvar(PKG_METADATA_UPDATE_AFTER = 2)
Sys.getenv("PKG_METADATA_UPDATE_AFTER")
#> [1] "2"
pkgdepends::current_config()
#> Error in rec$env_decode(envv, envvname, env): unused argument (env)

    Created on 2025-03-17 with reprex v2.1.1

    And if I enclose in quotes

    withr::local_envvar(PKG_SYSREQS_DB_UPDATE_TIMEOUT = "30")
Sys.getenv("PKG_SYSREQS_DB_UPDATE_TIMEOUT")
#> [1] "30"
pkgdepends::current_config()
#> Error in rec$env_decode(envv, envvname, env): unused argument (env)

    Created on 2025-03-17 with reprex v2.1.1

    withr::local_envvar(PKG_METADATA_UPDATE_AFTER = "2")
Sys.getenv("PKG_METADATA_UPDATE_AFTER")
#> [1] "2"
pkgdepends::current_config()
#> Error in rec$env_decode(envv, envvname, env): unused argument (env)

    Created on 2025-03-17 with reprex v2.1.1

  8. gaborcsardi
    added
    bugan unexpected problem or unintended behavior
    on Mar 17, 2025
  9. katrinabrock
    added 2 commits that reference this issue on Apr 14, 2025

    Workaround for r-lib/pak#755

    8b23441

    Workaround for r-lib/pak#755

    b5da12f

  10. katrinabrock commented on Apr 15, 2025

    @katrinabrock
    katrinabrock
    on Apr 15, 2025

    Hey, I'm also getting the same error:

    #> Error in rec$env_decode(envv, envvname, env): unused argument (env)

    When setting PKG_METADATA_UPDATE_AFTER to 30.

    Example here: https://github.com/stan-dev/cmdstanr/actions/runs/14465261844/job/40566077370#step:8:197

  11. katrinabrock commented on Apr 15, 2025

    @katrinabrock
    katrinabrock
    on Apr 15, 2025

    Potential fix (to error in workaround) here: r-lib/pkgdepends#442

  12. isaactpetersen commented on Apr 25, 2025

    @isaactpetersen
    isaactpetersen
    on Apr 25, 2025

    I have been frequently experiencing this error for months on many of my workflows. Is there a planned fix for this (apart from switching to older versions of ubuntu or other workarounds)?

  13. gaborcsardi commented on Apr 25, 2025

    @gaborcsardi
    gaborcsardi
    on Apr 25, 2025
    Member

    Have you tried the workaround at the beginning of #755 (comment)?

  14. gaborcsardi commented on Apr 25, 2025

    @gaborcsardi
    gaborcsardi
    on Apr 25, 2025
    Member

    Also, can you link to a recent failure?

  15. isaactpetersen commented on Apr 25, 2025

    @isaactpetersen
    isaactpetersen
    on Apr 25, 2025

    I have not tried the workaround. I was hoping that the issue would eventually be fixed and a workaround wouldn't be needed. However, if I'll need to use a workaround for the long-term, that would be helpful to know. Often it will resolve itself just by re-running the same workflow (it errors out sporadically--it errors out only sometimes and not every time, for some reason). In case it's still helpful to see a recent failure. Here is one:

    https://github.com/isaactpetersen/Fantasy-Football-Analytics-Textbook/actions/runs/14663387810/job/41152585226

    Thanks very much for your help with this.

  16. jgabry
    added a commit that references this issue on Aug 18, 2025

    Merge pull request #1077 from katrinabrock/workaround-pak-755

    175bfb4
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    bugan unexpected problem or unintended behavior

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions