[R-pkg-devel] How to (conditionally) use an archived package (without Suggests)?

On Sun, Feb 25, 2018 at 1:09 AM, Dirk Eddelbuettel <edd at debian.org> wrote:

On 25 February 2018 at 00:45, Marius Hofert wrote:
| A package 'foo' uses a package 'bar' (in Imports). 'bar' has been
| archived and the maintainer of 'foo' was asked to fix the dependency
| on 'bar' according to WRE 1.1.3.1.
|
| Working with 'bar::' everywhere (and requireNamespace("bar", quietly =
| TRUE)), as well as moving 'bar' from Imports to Suggests seems to work
| but is not accepted on submission. Removing 'bar' also from Suggests
| leads to
|
| '::' or ':::' import not declared from: ?bar?
| 'loadNamespace' or 'requireNamespace' call not declared from: ?bar?
|
| Does this mean it is not possible to use 'bar' anymore in 'foo'?

Your title says "conditionally".

Does your code actually behave conditionally, ie does foo check if bar is
available, and only use its code if it is?

Hi Dirk,

nice to hear from you and thanks for helping!

Yes, 'foo' essentially has one main function with an argument 'method
= c("b", "ba", "bar")'. If the user chooses to call the function with
method = "bar", then it is checked whether "bar" is installed (as
described in WRE) and an error is thrown if not.

One additional difficulty may be that even for Suggests, it still has to be
accessible "somewhere" .

The full story is this: 'bar' has been archived because 'problems were
not corrected despite reminders'. 'bar' is mainly developed on github
and is probably easy to fix, but I also couldn't reach the maintainer
and I thought it's better to 'decrease' the dependency on 'bar' as
much as possible. 'bar' is actually quite intrusive to install/use
(requires R to be configured with tcltk). However, 'bar' provides some
nice features which the other methods ("b", "ba") don't have -- would
be a pity to completely remove 'bar' from 'foo'.

So 'bar' is on github (and thus could be installed from there + 'foo'
could make use of 'bar' conditionally... just don't know how to submit
'foo' to CRAN because of the warning)

Cheers,
M

And "archived" is not.  You could just move bar
onto a drat repo you set yp -- we have done the same for data packages and
have a R Journal paper describing it:

    https://journal.r-project.org/archive/2017/RJ-2017-026/index.html

Hth, Dirk

--
http://dirk.eddelbuettel.com | @eddelbuettel | edd at debian.org

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.

On 24 February 2018 at 19:41, Duncan Murdoch wrote:
| Don't throw an error, work around it.  If you have no alternative code,
| then don't test the "bar" code unless "bar" is installed.
|
| The basic idea is that your package should pass tests without errors
| even if "bar" is not available.

100% agreed.

| I think Dirk is wrong saying that "bar" has to be available; CRAN isn't
| going to go looking for it.  But they do want your package to pass all
| tests even if none of the Suggests packages is available.

I might be wrong but I thought all package in Imports, LinkingTo, Depends and
Suggests are actually checked for availability.

CRAN and BioC work by default, others can be added via Additional_repository
in DESCRIPTION.  And as I recall, not mentioning one leads to some complaint
from R CMD check. But I may well misremember.

Best, Dirk

--
http://dirk.eddelbuettel.com | @eddelbuettel | edd at debian.org