Add "Remotes" field to DESC

[mpadge]

@santikka Your submission to rOpenSci (ropensci/software-review#554) failed checks because you've got minimal versions for both rstan and data.table that are beyond current CRAN versions (respectively 2.21.5 and 1.14.2, as of 18 Aug 2022). Your package fails to install because these version requirements can not be met.

You need to add these extra lines to your DESCRIPTION file:

Remotes:
  stan-dev/rstan,
  Rdatatable/data.table

That then tells the r-lib suite of installers (devtools, remotes) where to find those more recent versions, and so enables them to be installed. See docs of the remotes package for more info. Thanks 😄

[santikka]

@mpadge Thanks, adding now!

[santikka]

@mpadge Using the Remotes field doesn't seem to work for rstan, because the github repo doesn't actually contain the package. For some reason, I also got a compilation error when trying to install data.table from Rdatatable/data.table. Adding this to the DESCRIPTION file seems to work, at least when installing locally:

Additional_repositories: https://mc-stan.org/r-packages/,
    https://Rdatatable.gitlab.io/data.table

[mpadge]

@santikka Indeed, the "Remotes" field fails, and this "Additional_repositories" does work, but it only installs the latest release of the package, which for "rstan" is the current CRAN version. Their suggested method to "install the latest development version of RStan" then does not work, and there is no systematic way to get any system to install your minimal required version of >= 2.26.11. I would suggest you either:

1. need to take this issue up with the Stan dev team, and ask them to actually release a version that satisfies that, whether on CRAN or via their https://mc-stan.org/r-packages/ repository server. Without that, nobody else will really be able to install dynamite either.
2. Revise dynamite to somehow relax that depenency back to current CRAN / mc-stan.org version(s).

I've also updated our system so the bot would issue a notification that:

Note: The following R packages were unable to be installed/upgraded on our system: [rstan, StanHeaders]; some checks may be unreliable

I'm happy to keep tweaking our system to help here, so feel free to ask any further questions about how we can best solve this issue.

[santikka]

@mpadge Are you sure? If run this locally it installs rstan and StanHeaders version 2.26.13:

remove.packages(c("rstan", "StanHeaders"))
remotes::install_github("santikka/dynamite")

Also, our gh workflows for codecov and R CMD check manage to install the required versions by adding the repositories under extra-repositories in the yaml files. Could this be included in your system as well? For example our test-coverage.yaml is:

on:
  push:
    branches: [main, master]
  pull_request:
    branches: [main, master]

name: test-coverage

jobs:
  test-coverage:
    runs-on: ubuntu-latest
    env:
      GITHUB_PAT: ${{ secrets.GITHUB_TOKEN }}
      DYNAMITE_EXTENDED_TESTS: ${{contains(github.event.head_commit.message, 'run-extended')}}

    steps:
      - uses: actions/checkout@v2

      - uses: r-lib/actions/setup-r@v2
        with:
          extra-repositories: |
            https://mc-stan.org/r-packages/
            https://Rdatatable.gitlab.io/data.table
          use-public-rspm: true

      - uses: r-lib/actions/setup-r-dependencies@v2
        with:
          cache-version: 2
          extra-packages: |
            covr
            BH
            RcppParallel
            RcppEigen
            Rcpp
      - name: Test coverage
        run: covr::codecov()
        shell: Rscript {0}

[mpadge]

Are you sure?

Unfortuantely, yes, but since it works for you, it then suggests that it comes down to idiosyncracies of our build system. We use a non-standard docker container which enables full installation of any required system libraries that are then able to be cross-linked on compilation of any other packages. This present issue obviously reveals one disadvantage of our system. If it's okay, can you please keep this issue open while I investigate further to see what can be done. I'll get back on to it first thing next week. thanks 😄

(The gh-workflows file thing is something we discussed, but there really is no way to parse and use that information systematically, short of an assumption that everybody uses entirely standard r-lib-type workflows, which would be overly restrictive.)

[santikka]

That is unfortunate, I'll keep the issue open for now.

I'll also try to see if there is some way to use the Remotes field in DESC to install rstan and StanHeaders instead of the additional repos, if that is something that your system already supports.

[mpadge]

Thanks for helping with this @santikka . The problem definitely lies on our side now. I've got one idea on how i might be able to fix it, and will implement that this coming week. I'll close this issue on your repo now, and will let you know elsewhere when it's fixed.