Re: [R-pkg-devel] Winbuilder down?

[Balasubramanian Narasimhan]

Dear Uwe,

Mea culpa. that was a false alarm. I forgot that the email goes to the 
maintainer, which is not me. Apologies.


-Naras

On 2/1/24 7:40 AM, Uwe Ligges wrote:

Dear Naras,

the queues are empty, so everything has been processed.
Which package are you talking about? Then I can take a look what went 
wrong.


Best,
Uwe

On 01.02.2024 15:53, Balasubramanian Narasimhan wrote:
Just FYI: Winbuilder seems to be unresponsive. My uploads over the 
last 2 days have not resulted in any output or messages.


Thank you.

-Naras

__
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

[R-pkg-devel] Winbuilder down?

[Balasubramanian Narasimhan]

Just FYI: Winbuilder seems to be unresponsive. My uploads over the last 
2 days have not resulted in any output or messages.


Thank you.

-Naras

__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel

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

[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:

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



__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel

Re: [R-pkg-devel] How to update the email address of a package maintainer

[Balasubramanian Narasimhan]

Thank you, Simon!

On 11/8/21 5:57 PM, Simon Urbanek wrote:

 From CRAN Policy:



Explain any change in the maintainer’s email address and if possible send 
confirmation from the previous address (by a separate email to 
cran-submissi...@r-project.org) or explain why it is not possible



Cheers,
Simon



__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel

[R-pkg-devel] How to update the email address of a package maintainer

[Balasubramanian Narasimhan]

Is there any way at all to update the email address of the maintainer of 
a package? (The address of the maintainer of CVXR which is in need of an 
update for the new SCS solver has changed from  @stanford.edu to 
@alumni.stanford.edu, with no access to the former.)


-Naras

__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel

Re: [R-pkg-devel] Suggesting gurobi

[Balasubramanian Narasimhan]

Suggests" would trigger an attempt to install gurobi, which is not on CRAN.

We used "Enhances" for our CVXR  because

(1) None of the functionality in the package requires gurobi;

(2) Packages in "Enhances" are not required to check the package by CRAN.

Your package mirrors ours in these respects and so I would suggest going 
with "Enhances".


-Naras

On 6/4/21 12:35 PM, Noah Greifer wrote:

Hello,

I have been working on adding an option for my users to use integer
programming (a method of optimization) to enhance the results of a function
in my package. There are several R packages on CRAN that perform integer
programming, including Rglpk and Rsymphony. However, there is a commercial
solver called Gurobi that dramatically outperforms all open-source solvers,
and it comes with an R interface through the gurobi package. I want to
allow my users to use Gurobi to perform the package actions.

A potential issue is that the gurobi package is not on CRAN; it comes with
an installation of the Gurobi software, which requires a license. I am not
sure how to add gurobi to my Description file to satisfy CRAN's
requirements. In CMD CHECK, I get the warning that the package is not
available for checking. However, I have noticed some other packages do use
gurobi just as I want to (i.e., as an option), such as CVXR
 and designmatch
, which put gurobi in
Enhances (though I would have thought it would belong in Suggests). It
seems that neither of these packages passes the CRAN checks, though.

I'm wondering what the best practices are for including gurobi in my
package. To be clear, its use is optional and the package can be functional
without it, but it greatly enhances performance so I want my users to be
able to use it. Thank you!

Noah Greifer

[[alternative HTML version deleted]]

__
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

Re: [R-pkg-devel] Unable to get past CRAN submission checks for package cubature

[Balasubramanian Narasimhan]

Thanks to the encouragement of Brodie Gaslam and Tomas Kalibera (private 
email), I was able to hack the code to avoid the warnings.


The code in question had the following structure:

    int inibits = -1, bit;
    for( j = powers; j; j >>= 1 ) ++inibits;
    memcpy(pv, pini, inibits*sizeof(*pini));


which I changed to:

    int inibits = -1, bit;
    for( j = powers; j; j >>= 1 ) ++inibits;

    int sz = inibits * sizeof(*pini);
    sz = (sz > 0) ? sz : 0;

    memcpy(pv, pini, sz);

to guard against the erroneous gcc 8.3 inference that inibits could 
remain at -1 if powers is zero, known to be not possible.


Best,

-Naras

On 5/11/21 3:02 PM, brodie gaslam wrote:

At the risk of only being mildly (if at all) helpful, I was able
to reproduce your warnings on Rhub, which has the same compiler,
with:

     rhub::check('cubature_2.0.4.1.tar.gz', platform='windows-x86_64-release')

Absent feedback from CRAN you could try tweaking your code so that
it does not produce those warnings while no changing behavior.
Obviously, iterating with rhub is not the easiest way to do this,
but might be easier than trying to get GCC 8.3.

For reference, you might be hitting:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88273

Maybe you knew that already but it might be useful for others to be
aware there is an actual bug that at least is in the general area
that affects GCC 8.2-8.3.

Best,

B.




On Monday, May 10, 2021, 4:01:36 PM EDT, Balasubramanian Narasimhan 
 wrote:





I submitted a minor update of cubature (suggesting rmarkdown for
vignettes) and received a message that the package generated warnings.
However, the warnings were noted to be untrustworthy (see email below).
I noted this in the submission comments as well as the reply to the
auto-check email.

It appears that I am unable to get beyond the auto-check service. Any
suggestions?

-Naras

 Forwarded Message 

Subject:     Re: [CRAN-pretest-archived] CRAN submission cubature 2.0.4.2
Date:     Thu, 6 May 2021 12:51:37 -0700
From:     Balasubramanian Narasimhan 
To:     cran-submissi...@r-project.org, na...@stat.stanford.edu



Dear CRAN,

As explained in my submission comment, the warning is noted to be flaky
in the message below.

Thank you.

-Naras

On 18/03/2021 13:05, Kurt Hornik wrote:


Uwe Ligges writes:

Dear Naras,
your package cubature shows compiler warnings under Windows:
<https://cran.r-project.org/web/checks/check_results_cubature.html>
Any chance getting rid of these? Please try and resubmit.

Interestingly, r-release-macos shows this too ...

I think -Warray-bounds is known to be flaky in earlier compilers.  I do
not see this on macOS with Apple Clang 11.5 (latest for High Sierra) or
12.4 (current) and nor does Tomas for GCC 10 on Windows.




__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel

[R-pkg-devel] Unable to get past CRAN submission checks for package cubature

[Balasubramanian Narasimhan]

I submitted a minor update of cubature (suggesting rmarkdown for 
vignettes) and received a message that the package generated warnings. 
However, the warnings were noted to be untrustworthy (see email below). 
I noted this in the submission comments as well as the reply to the 
auto-check email.

It appears that I am unable to get beyond the auto-check service. Any 
suggestions?

-Naras

 Forwarded Message 

Subject:Re: [CRAN-pretest-archived] CRAN submission cubature 2.0.4.2
Date:   Thu, 6 May 2021 12:51:37 -0700
From:   Balasubramanian Narasimhan 
To: cran-submissi...@r-project.org, na...@stat.stanford.edu



Dear CRAN,

As explained in my submission comment, the warning is noted to be flaky 
in the message below.

Thank you.

-Naras

On 18/03/2021 13:05, Kurt Hornik wrote:

>>>>>> Uwe Ligges writes:
>
>> Dear Naras,
>> your package cubature shows compiler warnings under Windows:
>> <https://cran.r-project.org/web/checks/check_results_cubature.html>
>
>> Any chance getting rid of these? Please try and resubmit.
>
> Interestingly, r-release-macos shows this too ...

I think -Warray-bounds is known to be flaky in earlier compilers.  I do 
not see this on macOS with Apple Clang 11.5 (latest for High Sierra) or 
12.4 (current) and nor does Tomas for GCC 10 on Windows.


-- 
Brian D. Ripley, rip...@stats.ox.ac.uk
Emeritus Professor of Applied Statistics, University of Oxford
On 5/6/21 12:27 PM, lig...@statistik.tu-dortmund.de wrote:
> Dear maintainer,
>   
> package cubature_2.0.4.2.tar.gz does not pass the incoming checks 
> automatically, please see the following pre-tests:
> Windows:<https://win-builder.r-project.org/incoming_pretest/cubature_2.0.4.2_20210506_211603/Windows/00check.log>
> Status: 1 WARNING
> Debian:<https://win-builder.r-project.org/incoming_pretest/cubature_2.0.4.2_20210506_211603/Debian/00check.log>
> Status: OK
>   
> Last released version's CRAN status: WARN: 3, NOTE: 10
> See:<https://CRAN.R-project.org/web/checks/check_results_cubature.html>
>   
> CRAN Web:<https://cran.r-project.org/package=cubature>
>   
> Please fix all problems and resubmit a fixed version via the webform.
> If you are not sure how to fix the problems shown, please ask for help on the 
> R-package-devel mailing list:
> <https://stat.ethz.ch/mailman/listinfo/r-package-devel>
> If you are fairly certain the rejection is a false positive, please reply-all 
> to this message and explain.
>   
> More details are given in the directory:
> <https://win-builder.r-project.org/incoming_pretest/cubature_2.0.4.2_20210506_211603/>
> The files will be removed after roughly 7 days.
>   
> *** Strong rev. depends ***: ALTopt apTreeshape bivquant BNSP calibrator 
> clusteredinterference coga cold dbmss DRAYL dvmisc ei equivalenceTest 
> fMultivar GAS GB2 GPCMlasso GRCdata highfrequency hyper2 ICAOD inctools 
> MCMCglmm MIRES MMDCopula MWright NonNorMvtDist np OBASpatial ODS optimStrat 
> PCMRS planar pooling Power2Stage PowerTOST ProFit QGglmm robustlmm skedastic 
> SphericalCubature spNetwork statsr SurvDisc symmoments TCIU tseriesEntropy 
> UPCM vines WLinfer yuima
>   
> Best regards,
> CRAN teams' auto-check service
>
> Flavor: r-devel-linux-x86_64-debian-gcc, r-devel-windows-ix86+x86_64
> Check: CRAN incoming feasibility, Result: Note_to_CRAN_maintainers
>Maintainer: 'Balasubramanian Narasimhan'
>
> Flavor: r-devel-windows-ix86+x86_64
> Check: whether package can be installed, Result: WARNING
>Found the following significant warnings:
>  ./src/common/Random.c:105:5: warning: 'memcpy' pointer overflow between 
> offset 0 and size [4294967292, 2147483647] [-Warray-bounds]
>  ./src/common/Random.c:105:5: warning: 'memcpy' pointer overflow between 
> offset 0 and size [-4, 9223372036854775807] [-Warray-bounds]
>See 'd:/RCompile/CRANincoming/R-devel/cubature.Rcheck/00install.out' for 
> details.

[[alternative HTML version deleted]]

__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel

Re: [R-pkg-devel] Subarchitectures

[Balasubramanian Narasimhan]

If GNU make is acceptable as a system requirement, you can get any R 
configuration/runtime variable in Makevars, e.g.


R_ARCH=$(shell $(R_HOME)/bin/Rscript -e 'cat(.Platform$r_arch)')

-Naras

On 2/9/21 9:45 AM, Duncan Murdoch wrote:

On 09/02/2021 11:01 a.m., Duncan Murdoch wrote:

I think the WRE manual says that an R_ARCH environment variable will be
set when subarchitectures are involved, but environment variables aren't
accessible in Makevars.


Actually, I probably misread the section about environment variables.

Duncan

__
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

[R-pkg-devel] Winbuilder seems stuck

[Balasubramanian Narasimhan]

This is just FYI to CRAN as no results came back from an upload over a 
day and a half ago. A repeat upload gives:

ERROR: Access to the path 'C:\Inetpub\ftproot\R-devel\...' is denied.

-Naras



[[alternative HTML version deleted]]

__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel

Re: [R-pkg-devel] checking windows timing?

[Balasubramanian Narasimhan]

FWIW, we dealt with the tests-taking-too-long problem for CVXR (which 
has a lot of tests) by mercilessly cutting out all tests on CRAN 
(testthat::skip_on_cran()) except for some fundamental ones on atoms, 
curvature, etc.  We then rely on Github actions (with NOT_CRAN = true) 
to run the full test suite on several platforms. Not perfect, but that's 
what worked for us.


-Naras

On 10/13/20 9:46 AM, Ben Bolker wrote:


  Following up on my questions from yesterday:

  I've been advised to (drastically) reduce the checking time of my 
package on CRAN's Windows platform (currently at 23 min). I've gone 
through and added a lot of conditionals to skip tests on CRAN.  I 
could reduce it farther but I'm starting to encounter seriously 
diminishing returns, e.g.


 * do I condition out some particular test that takes 6 seconds? 
(e.g., a little slow, but not egregious)
 * do I put \dontrun{} around an example that takes 6 seconds [I'm a 
bit confused about this, but as I understand it CRAN checks with 
--run-donttest ? \dontrun{} also sometimes provokes complaints from 
CRAN, because "you should only use \dontrun{} for code that cannot be 
run by users" ...]


  I don't want to spend forever tweaking things, and I don't want to 
comment/condition out all of my tests, but I would really prefer to 
avoid bouncing from CRAN again. I don't know a *reliable* way to test 
whether CRAN-checking on Windows will take <10 mins or not ...


  I don't have a local Windows test platform.

  win-builder gives timings for long-running components, but not for 
the whole run.


  r-hub gives a time for the entire build (19 min in my case) - but 
this includes the time to set up the virtual machine, install all 
packages, etc..


  I can approximately predict that most examples and tests will take 
twice as long on CRAN's windows machines (and four times as long since 
tests, at least, are checked on both i386 and x86_64 architectures).


  Testing is currently taking 6 minutes on my local machine (newish 
Ubuntu 18.04 laptop), so I guess have more work to do, but I wonder if 
anyone has suggestions ...


  cheers
    Ben Bolker

__
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

Re: [R-pkg-devel] Help in getting past CRAN submission rejections

[Balasubramanian Narasimhan]

Just to close the loop on this: the drat suggestion for both packages 
and also moving things to enhances worked. I could do this also for 
Gurobi because it is LGPL'd. Thanks Toby and Dirk (for drat).


-Naras

On 9/9/20 5:16 PM, Balasubramanian Narasimhan wrote:

Thanks Toby, so there is hope.  The drat suggestion for rcbc is worth a
try, gurobi is noted as you recommend.

-Naras

On 9/9/20 4:38 PM, Toby Hocking wrote:

Hi Naras
I had a similar issue recently with
https://cloud.r-project.org/web/packages/nc/ --- it Suggests: re2r
which is a package that is no longer on CRAN, but available on github.
To solve the issue I just copied the re2r into a drat repo, which is a
CRAN-like repository hosted on github. More info on drat here
http://eddelbuettel.github.io/drat/DratForPackageAuthors.html So if
those solver packages you have in Suggests are open-source, you can
just copy them to your drat repo, and list that drat repo in
Additional_repositories. If they aren't open-source then you should
provide a description of how to obtain those packages in Description.
Something like "gurobi package is not available in any public
open-source repositories but can be downloaded for academic use free
of charge from $GUROBI_URL"
BTW thanks for your efforts in getting CVXR on CRAN, that is really
important work!
Toby


On Wed, Sep 9, 2020 at 10:40 AM Balasubramanian Narasimhan
mailto:na...@stanford.edu>> wrote:

 We've been struggling to get past CRAN's rejections for a new
 upload of
 CVXR.  The new version makes essentially one change to the existing
 version on CRAN: the addition of a DOI to an article to appear in
 JSS.
 We realize that CRAN may tighten policies in the meantime forcing
 some
 changes to be made, which we are happy to do. But we are not sure
 what.

 The automated check
 
<https://win-builder.r-project.org/incoming_pretest/CVXR_1.0-6_20200908_223033/>

 came back with 2 notes on Debian and Windows, both addressed in
 replies
 and submission comments. (Solaris failures are expected, also noted.)

 The communications with CRAN indicates that the problem might be that
 our package (the current version too) _suggests_ solvers not
 available
 on CRAN. These are either on github or on vendor websites (free to
 academics after login).  One reply from CRAN suggested that we either
 use the "Additional_repositories" field or provide some text in
 Description. The former is not applicable---these are not CRAN-like
 repositories---so we added text in the description with URL links.

 What could we be missing?

 Thanks.

 -Naras

 __
 R-package-devel@r-project.org
 <mailto:R-package-devel@r-project.org> mailing list
 https://stat.ethz.ch/mailman/listinfo/r-package-devel


[[alternative HTML version deleted]]

__
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

Re: [R-pkg-devel] Help in getting past CRAN submission rejections

[Balasubramanian Narasimhan]

Thanks Toby, so there is hope.  The drat suggestion for rcbc is worth a 
try, gurobi is noted as you recommend.

-Naras

On 9/9/20 4:38 PM, Toby Hocking wrote:
> Hi Naras
> I had a similar issue recently with 
> https://cloud.r-project.org/web/packages/nc/ --- it Suggests: re2r 
> which is a package that is no longer on CRAN, but available on github. 
> To solve the issue I just copied the re2r into a drat repo, which is a 
> CRAN-like repository hosted on github. More info on drat here 
> http://eddelbuettel.github.io/drat/DratForPackageAuthors.html So if 
> those solver packages you have in Suggests are open-source, you can 
> just copy them to your drat repo, and list that drat repo in 
> Additional_repositories. If they aren't open-source then you should 
> provide a description of how to obtain those packages in Description. 
> Something like "gurobi package is not available in any public 
> open-source repositories but can be downloaded for academic use free 
> of charge from $GUROBI_URL"
> BTW thanks for your efforts in getting CVXR on CRAN, that is really 
> important work!
> Toby
>
>
> On Wed, Sep 9, 2020 at 10:40 AM Balasubramanian Narasimhan 
> mailto:na...@stanford.edu>> wrote:
>
> We've been struggling to get past CRAN's rejections for a new
> upload of
> CVXR.  The new version makes essentially one change to the existing
> version on CRAN: the addition of a DOI to an article to appear in
> JSS.
> We realize that CRAN may tighten policies in the meantime forcing
> some
> changes to be made, which we are happy to do. But we are not sure
> what.
>
> The automated check
> 
> <https://win-builder.r-project.org/incoming_pretest/CVXR_1.0-6_20200908_223033/>
>
> came back with 2 notes on Debian and Windows, both addressed in
> replies
> and submission comments. (Solaris failures are expected, also noted.)
>
> The communications with CRAN indicates that the problem might be that
> our package (the current version too) _suggests_ solvers not
> available
> on CRAN. These are either on github or on vendor websites (free to
> academics after login).  One reply from CRAN suggested that we either
> use the "Additional_repositories" field or provide some text in
> Description. The former is not applicable---these are not CRAN-like
> repositories---so we added text in the description with URL links.
>
> What could we be missing?
>
> Thanks.
>
> -Naras
>
> __
> R-package-devel@r-project.org
> <mailto:R-package-devel@r-project.org> mailing list
> https://stat.ethz.ch/mailman/listinfo/r-package-devel
>

[[alternative HTML version deleted]]

__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel

[R-pkg-devel] Help in getting past CRAN submission rejections

[Balasubramanian Narasimhan]

We've been struggling to get past CRAN's rejections for a new upload of 
CVXR.  The new version makes essentially one change to the existing 
version on CRAN: the addition of a DOI to an article to appear in JSS.  
We realize that CRAN may tighten policies in the meantime forcing some 
changes to be made, which we are happy to do. But we are not sure what.


The automated check 
 
came back with 2 notes on Debian and Windows, both addressed in replies 
and submission comments. (Solaris failures are expected, also noted.)


The communications with CRAN indicates that the problem might be that 
our package (the current version too) _suggests_ solvers not available 
on CRAN. These are either on github or on vendor websites (free to 
academics after login).  One reply from CRAN suggested that we either 
use the "Additional_repositories" field or provide some text in 
Description. The former is not applicable---these are not CRAN-like 
repositories---so we added text in the description with URL links.


What could we be missing?

Thanks.

-Naras

__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel

[R-pkg-devel] Uncaught use of internal functions from other packages in R CMD check

[Balasubramanian Narasimhan]

At least one package on CRAN uses

get("foo", envir=asNamespace("imported_package"))

and passes check.

Is this known?

-Naras

__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel

Re: [R-pkg-devel] How to account for optional packages not necessarily on CRAN

[Balasubramanian Narasimhan]

Thanks Dirk!  I did not realize that suggested packages are not required 
to be on primary repos like CRAN, BioC.  We do indeed condition our code 
to check that. So I guess, we are good to go, as is.


I will, in due time, read the paper too...

-N

On 12/10/19 5:52 PM, Dirk Eddelbuettel wrote:

On 10 December 2019 at 17:22, Balasubramanian Narasimhan wrote:
| We've run into the following problem in integrating commercial and open
| source solvers in to our package CVXR. We have "Suggests" dependency on
| some packages that may not be available to CRAN.
|
| There are two main scenarios.
|
| 1. A suggested meta-package is on CRAN, e.g. Rmosek, but the user must
| further take action to ensure the binary is installed.  The recommended
| requireNamespace("Rmosek", quietly = TRUE) is insufficient to guarantee
| the functionality desired even if it succeeds.
|
| 2. A suggested package is on github or a commercial vendor site only.
| The package code has references to such packages in the code, causing
| problems while checking on CRAN.
|
| It would seem, at least for 2 above, that separating the suggested
| functionality into other packages can ensure that birds of the same
| feather can flock together. But the shared internals make this
| impossible to do at the moment.
|
| The only thing I can think of is to ask CRAN to consider
| _R_FORCE_CHECK_SUGGESTS_= 0 for such a package. Am I missing anything?

You could use drat (or, if you prefer, roll a CRAN repo by hand) to host a
"CRAN-alike" repo on, say, GitHub or any other http(s)-accessible site, and
then use Additional_repository: with it.

Brooke and I have a fully worked in example for the case of large data
packages in the R Journal:

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

Hosting Data Packages via drat: A Case Study with Hurricane Exposure Data

G. Brooke Anderson and Dirk Eddelbuettel , The R Journal (2017) 9:1, pages
486-497.

Abstract Data-only packages offer a way to provide extended functionality
for other R users. However, such packages can be large enough to exceed
the package size limit (5 megabytes) for the Comprehen sive R Archive
Network (CRAN). As an alternative, large data packages can be posted to
additional repostiories beyond CRAN itself in a way that allows smaller
code packages on CRAN to access and use the data. The drat package
facilitates creation and use of such alternative repositories and makes it
particularly simple to host them via GitHub. CRAN packages can draw on
packages posted to drat repositories through the use of the
‘Additonal_repositories’ field in the DESCRIPTION file. This paper
describes how R users can create a suite of coordinated packages, in which
larger data packages are hosted in an alternative repository created with
drat, while a smaller code package that interacts with this data is
created that can be submitted to CRAN.

Don't be misled by 'data' here--it works the same way with code. And it is
the _one_ option you have because Suggests: are not required to be on a
primary repo like CRAN or BioC.  Naturally, you then need to condition your
code on "is it here yet?" but you likely already do.

Hope this helps,  Dirk



__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel

[R-pkg-devel] How to account for optional packages not necessarily on CRAN

[Balasubramanian Narasimhan]

We've run into the following problem in integrating commercial and open 
source solvers in to our package CVXR. We have "Suggests" dependency on 
some packages that may not be available to CRAN.


There are two main scenarios.

1. A suggested meta-package is on CRAN, e.g. Rmosek, but the user must 
further take action to ensure the binary is installed.  The recommended 
requireNamespace("Rmosek", quietly = TRUE) is insufficient to guarantee 
the functionality desired even if it succeeds.


2. A suggested package is on github or a commercial vendor site only. 
The package code has references to such packages in the code, causing 
problems while checking on CRAN.


It would seem, at least for 2 above, that separating the suggested 
functionality into other packages can ensure that birds of the same 
feather can flock together. But the shared internals make this 
impossible to do at the moment.


The only thing I can think of is to ask CRAN to consider 
_R_FORCE_CHECK_SUGGESTS_= 0 for such a package. Am I missing anything?


Thank you.

-Naras

__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel