CRAN friendly Remotes field in Description

[jeffreyhanson]

Hi,

Thanks so much for all your work on developing the remotes package! It's extremely useful for installing packages and handling package dependencies that aren't on CRAN. I use the Remotes field in the DESCRIPTION file for many packages to provide automated install options for soft dependencies that aren't on CRAN. However, this creates an issue when submitting packages to CRAN, because the CRAN package checks throw a NOTE (if I remember correctly) if submissions contain a Remotes field. In practice, this means that I have to manually temporarily delete the Remotes field when making CRAN submissions. To provide a seamless experience that does not require manually altering DESCRIPTION files during CRAN submission, it would be nice if the remotes package also recognized a remotes field in the DESCRIPTION that passes CRAN package checks. My understanding is that the DESCRIPTION fields that start with Config/ do not throw such NOTES and are acceptable under CRAN package checks (e.g., because dplyr has such Config/* fields in its DESCRIPTION on CRAN), and so perhaps supporting a Config/Remotes DESCRIPTION field would work?

How does that sound?

[gaborcsardi]

First of all, I suggest using pak instead of remotes, if you can. For many use cases it works much better and that's where current development is happening.

It is intentional that Remotes is a field that is not allowed on CRAN, to prevent accidentally publishing packages that rely on development version or non-CRAN packages.

You can already use the Config/ fields for dependencies, e.g. you can tell pak to also install packages in Config/Needs/website:

pak::pkg_install(..., dependencies = c("all, "Config/Needs/website"))

[jeffreyhanson]

Thank you very much for the rapid repsonse! I really appreciate it.

Ah I see - thanks for explaining that about pak - that's good to know.

Yeah, that's a really good point regarding CRAN submissions. I agree that it's useful to prevent accidently publishing packages that have developmental or non-CRAN packages listed as hard dependencies, and I'm looking for a strategy to support publishing packages that have non-CRAN packages listed as soft dependencies (since this is permitted per CRAN policies) (also, I am aware of the Additional_repositories field, but would prefer not to use it).

Thanks! I didn't realize that the Config/Needs field could already be used for this purpose. Just to clarify, would this be accomplished by specifying the soft dependency in both Suggests and Config/Needs/website?

To test this out, I've made a developmental branch (prioritizr/wdpar@config-remotes) which has the GitHub-only package prepr listed in Suggests and Config/Needs/website (see https://github.com/prioritizr/wdpar/blob/config-remotes/DESCRIPTION#L63-L64). I can succesfully install all of the soft dependencies (including the GitHub-only package prepr listed under Suggests and relying on Config/Needs/website to provide the GitHub repo details) using the code below. It appears to work, but I just thought I'd check?

pak::pkg_install("prioritizr/wdpar@config-remotes", dep=c("all", "Config/Needs/website"))

Also, since I would be using Config/Needs/website for a different purpose than building package websites, I was wondering if it would be a good idea to use a different name for this field (e.g., Config/Needs/suggests, Config/Needs/remotes, or Config/Needs/check) to avoid breaking standard practices. Do you have any particular preference? I just don't want to set a bad precedent in case other people see this thread, start using Config/Needs/website for non-intended/standard purposes, and create more issues/work for you later on?

[gaborcsardi]

Just to clarify, would this be accomplished by specifying the soft dependency in both Suggests and Config/Needs/website?

No, it is enough to have it in Config/Needs/*.

Do you have any particular preference?

No, you can use any name you like. If you are paranoid prefix it with your package name.

[jeffreyhanson]

Ah, I see - thank you!

That's interesting to hear that the soft-dependency would only need to be listed under Config/Needs/*. I was under impression that CRAN package checks would throw a WARNING if a dependency is not specified under Imports,
Depends, or Suggests. To test this out, I removed prepr from Suggests so it is only listed under Config/Needs/* and then ran devtools::check(). Based on the logs (see below), it appears to throw a WARNING when the soft dependency is only listed under Config/Needs/* - but maybe I am doing something wrong? Sorry, I realize this is tangential to the original question, but I just want to make sure that I'm following best practices with Config/Needs/*.

---

══ Checking ════════════════════════════════════════════════════════════════════
Setting env vars:
• _R_CHECK_CRAN_INCOMING_USE_ASPELL_           : TRUE
• _R_CHECK_CRAN_INCOMING_REMOTE_               : FALSE
• _R_CHECK_CRAN_INCOMING_                      : FALSE
• _R_CHECK_FORCE_SUGGESTS_                     : FALSE
• _R_CHECK_PACKAGES_USED_IGNORE_UNUSED_IMPORTS_: FALSE
• NOT_CRAN                                     : true
── R CMD check ─────────────────────────────────────────────────────────────────
* using log directory ‘/tmp/RtmpeqvRVy/filee0833a791967/wdpar.Rcheck’
* using R version 4.4.1 (2024-06-14)
* using platform: x86_64-pc-linux-gnu
* R was compiled by
    gcc (Ubuntu 11.4.0-1ubuntu1~22.04) 11.4.0
    GNU Fortran (Ubuntu 11.4.0-1ubuntu1~22.04) 11.4.0
* running under: Ubuntu 22.04.5 LTS
* using session charset: UTF-8
* using options ‘--run-donttest --no-manual --ignore-vignettes --as-cran’
* checking for file ‘wdpar/DESCRIPTION’ ... OK
* checking extension type ... Package
* this is package ‘wdpar’ version ‘1.3.8’
* package encoding: UTF-8
* checking package namespace information ... OK
* checking package dependencies ... OK
* checking if this is a source package ... OK
* checking if there is a namespace ... OK
* checking for executable files ... OK
* checking for hidden files and directories ... OK
* checking for portable file names ... OK
* checking for sufficient/correct file permissions ... OK
* checking whether package ‘wdpar’ can be installed ... OK
* checking installed package size ... OK
* checking package directory ... OK
* checking for future file timestamps ... OK
* checking DESCRIPTION meta-information ... OK
* checking top-level files ... OK
* checking for left-over files ... OK
* checking index information ... OK
* checking package subdirectories ... OK
* checking code files for non-ASCII characters ... OK
* checking R files for syntax errors ... OK
* checking whether the package can be loaded ... OK
* checking whether the package can be loaded with stated dependencies ... OK
* checking whether the package can be unloaded cleanly ... OK
* checking whether the namespace can be loaded with stated dependencies ... OK
* checking whether the namespace can be unloaded cleanly ... OK
* checking loading without being on the library search path ... OK
* checking whether startup messages can be suppressed ... OK
* checking dependencies in R code ... WARNING
'::' or ':::' import not declared from: ‘prepr’
'loadNamespace' or 'requireNamespace' call not declared from: ‘prepr’
[... removed subsequent logs because they are not relevant ...]

[gaborcsardi]

Yes, if the package is picked up by R CMD check you need to list it in Suggests, otherwise the check will fail

To get it installed by pak, it is enough to list it at Config/Needs/*.

[jeffreyhanson]

Ah ok - thanks for clarifying that. I think you've answered all my questions and I can understand the rationale for not supporting a Config/Remotes field (in addition to a Remotes field), so I'll close this issue. Thanks again!