Skip to content

[R-pkg-devel] [UNCLASSIFIED] Remotes in description when submitting a package until a dependency is fixed

6 messages · Bernd.Gruber, Hugh Parsonage, Duncan Murdoch +3 more

Original
Bernd.Gruber
# 
Hi,

I have a package (dartR) that needs to be updated by CRAN (and got a time set until a certain date). It depends on a package that is currently showing errors in the CRAN results and therefore fails. The maintainer of that package is busily trying to rectify the error (as can be seen be repeated submissions in the last weeks), but was not able yet to fix it. As we are running out of time my approach would be to have a version of the package that fixes it and use Remotes: in the description. It runs fine without errors.

In the R-packages book I read the following:

"It's important to note that you should not submit your package to CRAN in the intermediate state, meaning with a Remotes field and with a dependency required at a version that's not available from CRAN or Bioconductor. For CRAN packages, this can only be a temporary development state, eventually resolved when the dependency updates on CRAN and you can bump your minimum version accordingly."

So is it okay to submit our package with a remote statement until the maintainer of the other package has fixed their issues?

Thanks in advance,
Bernd


==============================================================================
Dr Bernd Gruber                                              )/_
                                                         _.--..---"-,--c_
Professor Ecological Modelling                      \|..'           ._O__)_
Tel: (02) 6206 3804                         ,=.    _.+   _ \..--( /
Fax: (02) 6201 2328                           \\.-''_.-' \ (     \_
Institute for Applied Ecology                  `'''       `\__   /\
Faculty of Science and Technology                          ')
University of Canberra   ACT 2601 AUSTRALIA
Email: bernd.gruber at canberra.edu.au<mailto:bernd.gruber at canberra.edu.au>
WWW: bernd-gruber<https://researchprofiles.canberra.edu.au/en/persons/bernd-gruber>
==============================================================================

[UC Logo]<http://www.canberra.edu.au>

[Its time to control your Future. Apply now to study with Australia's fastest rising University. *QS, 2022]<https://www.canberra.edu.au/>



The Ngunnawal people are the Traditional Custodians of the ACT where UC's Bruce Campus is situated and are an integral and celebrated part of UC's culture. We also acknowledge other First Nations Peoples.

Australian Government Higher Education Registered Provider (CRICOS) #00212K. TEQSA Provider ID: PRV12003 (Australian University)
Email Disclaimer<https://www.canberra.edu.au/about-uc/disclaimer-copyright-privacy-accessibility>

[UC Facebook]<https://www.facebook.com/UniversityOfCanberra>    [UC Twitter] <https://twitter.com/UniCanberra>     [UC Instagram] <https://www.instagram.com/unicanberra/>     [UC Linkedin] <https://au.linkedin.com/school/university-of-canberra/>     [UC Youtube] <https://www.youtube.com/user/uniofcanberra>     [University of Canberra] <http://www.canberra.edu.au>
Hugh Parsonage
# 
I think you've misunderstood that excerpt.  By "temporary development
state", it means _between_ CRAN releases; packages in a development
state are not suitable for CRAN, as the policy states:
You'll need to stop depending on that package until it's fixed and the
fix is on CRAN. That said, it looks like it might be relatively
straightforward to disentangle yourself from the package -- just
rewrite the offending example?
On Wed, 16 Nov 2022 at 15:35, Bernd.Gruber <Bernd.Gruber at canberra.edu.au> wrote:
Duncan Murdoch
#
On 15/11/2022 11:59 p.m., Hugh Parsonage wrote:
Another solution is to put a version of that package in your own drat 
repository, and use "Additional_repositories".  For example, at one 
point rgl used webshot2 before it was released, and I had

   Suggests:  webshot2, ...
   Additional_repositories:  https://dmurdoch.github.io/drat

with a copy of webshot2 in the drat repository.

The disadvantage of this approach is that you'll need to keep that 
repository up to date as the third party package evolves, and eventually 
remove the Additional_repositories: line from your DESCRIPTION, which 
requires your own package update.

See https://github.com/eddelbuettel/drat for instructions on setting up 
the drat repository.

Duncan Murdoch
Dirk Eddelbuettel
#
On 16 November 2022 at 06:36, Duncan Murdoch wrote:
| On 15/11/2022 11:59 p.m., Hugh Parsonage wrote:
| > I think you've misunderstood that excerpt.  By "temporary development
| > state", it means _between_ CRAN releases; packages in a development
| > state are not suitable for CRAN, as the policy states:
| > 
| >> CRAN hosts packages of publication quality and is not a development platform.
| > 
| > You'll need to stop depending on that package until it's fixed and the
| > fix is on CRAN. That said, it looks like it might be relatively
| > straightforward to disentangle yourself from the package -- just
| > rewrite the offending example?
| 
| Another solution is to put a version of that package in your own drat 
| repository, and use "Additional_repositories".  For example, at one 
| point rgl used webshot2 before it was released, and I had
| 
|    Suggests:  webshot2, ...
|    Additional_repositories:  https://dmurdoch.github.io/drat
| 
| with a copy of webshot2 in the drat repository.
| 
| The disadvantage of this approach is that you'll need to keep that 
| repository up to date as the third party package evolves, and eventually 
| remove the Additional_repositories: line from your DESCRIPTION, which 
| requires your own package update.
| 
| See https://github.com/eddelbuettel/drat for instructions on setting up 
| the drat repository.

(Disclaimer: Author bias here.) Let me vouch for Additional_repositories:
along with packages in Suggests: (you cannot do this for Imports / Depends /
LinkingTo per CRAN Policy).  I have recently been relying on it a lot for a
package I (similarly) could not change that frequently at CRAN, and a
'semi-private / semi-public package' providing functionality I expect to be
provided by another package 'eventually'. With the caveat that you need the
Suggests: mechanism and hence _conditional_ use, it works just like CRAN.

In the meantime Additional_repositories: just works. It expands the set of
repos, so all operations relying on standard install.packages() calls (and
that includes using the remotes package to parse dependencies in CI, say)
just work, both at CRAN and in CI.

`drat` simply helps along by making it easier to provide compatible repositories.

Dirk
Henrik Bengtsson
# 
Not sure if it's already been said, but note that we can only use
'Additional_repositories' for *optional* dependencies, which are
listed under 'Suggests' (and less used 'Enhances').  We cannot use
them for *hard* dependencies, which are listed under 'Depends' or
'Imports'. From the CRAN Policies
(https://cran.r-project.org/web/packages/policies.html):

"Packages on which a CRAN package depends should be available from a
mainstream repository: if any mentioned in ?Suggests? or ?Enhances?
fields are not from such a repository, where to obtain them at a
repository should be specified in an ?Additional_repositories? field
of the DESCRIPTION file (as a comma-separated list of repository URLs)
or for other means of access, described in the ?Description? field."

Currently, it's only CRAN and Bioconductor that are "mainstream" repositories.

/Henrik
On Wed, Nov 16, 2022 at 3:36 AM Duncan Murdoch <murdoch.duncan at gmail.com> wrote:
12 days later
Balasubramanian Narasimhan
# 
(Disclaimer: User bias here.)

I can vouch for drat repos; they have saved me in developing APIs for 
packages under development, e.g. rcbc which is only on Github and not on 
CRAN.? (As Dirk notes, this only applies to Enhances/Suggests dependence.)

-Naras
On 11/16/22 8:17 AM, Dirk Eddelbuettel wrote: