The relevant part of the repository policy: > 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.
My understanding is that "should be available" means "if it's not available, expect a NOTE (at least) and you should address this note in your submission". Also, I think "available" means "available and installable". For example, I get a NOTE for 'taxstats', a suggested package of grattan that isn't on CRAN: * checking CRAN incoming feasibility ... NOTE Suggests or Enhances not in mainstream repositories: taxstats Availability using Additional_repositories specification: taxstats yes https://hughparsonage.github.io/drat/ However, the reason taxstats is not on CRAN is because it's too big, not because it's unable to be installed or has other problems. At the time it was archived, package loon could only be installed on OSX as far as I can see, which may disqualify it from even being suggested. My understanding is that CRAN does indeed check the package with non-mainstream packages installed (at least on initial submission). You may be better off just hoisting the functions you need outside of loon (with attribution and while respecting the licence) if you really need them. (You say that package loon's problems are easy to fix. You may be able to accede to be its maintainer but I don't know the details of this process. The CRAN repository policy contemplates this when the package is orphaned, but I'm not sure if it's the same process when the package is archived.) On 25 February 2018 at 11:59, Dirk Eddelbuettel <e...@debian.org> wrote: > > 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 | e...@debian.org > > ______________________________________________ > R-package-devel@r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-package-devel ______________________________________________ R-package-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel
