Re: [R-pkg-devel] suggestion: conda for third-party software
On Tue, 7 Jan 2020 15:49:45 +0100 Serguei Sokol wrote: > Currently, many R packages include TPS as part of them thus bloating > their sizes and often duplicating files on a given system. And even > when TPS is not included in an R package but is just installed on a > system, it is not so obvious to get the right path to it. Sometimes > pkg-config helps but it is not always present. I agree that making a package depend on a third-party library means finding oneself in a bit of a pickle. A really popular library like cURL could be "just" depended upon (for the price of some problems when building on Windows). A really small (e.g. 3 source files) and rarely updated (just once last year) library like liborigin could "just" be bundled (but the package maintainer would have to constantly watch out for new versions of the library). Finding that the bundled version of a network-facing library in an R package (e.g. libuv in httpuv) is several minor versions out of date is always a bit scary, even if it turns out that no major security flaws have been found in that version (just a few low-probability resource leaks, one unlikely NULL pointer dereference and some portability problems). The road to dependency hell is paved with intentions of code reuse. > So, the new feature would be to let R package developers to write in > DESCRIPTION/SystemRequirements field something like > 'conda:boost-cpp>=1.71' where 'boost-cpp' is an example of a conda > package and '>=1.71' is an optional version requirement. While I appreciate the effort behind Anaconda, I would hate to see it being *required* to depend on third-party binaries compiled by a fourth-party (am I counting my parties right?) when there's already a copy installed and available via means the user trusts more (e.g. via GNU/Linux distro package, or Homebrew on macOS, or just a copy sitting in /usr/local installed manually from source). In this regard, a separate field like "Config/conda" suggested by Kevin Ushey sounds like a good idea: if one wants to use Anaconda, the field is there. If one doesn't, one can just ignore it and provide the necessary dependencies in a different way. -- Best regards, Ivan __ R-package-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel
Re: [R-pkg-devel] suggestion: conda for third-party software
Thanks for this hint. Le 07/01/2020 à 20:47, Kevin Ushey a écrit : The newest version of reticulate does something very similar: R packages can declare their Python package dependencies in the Config/reticulate field of a DESCRIPTION file, and reticulate can read and use those dependencies to provision a Python environment for the user when requested (currently using Miniconda). If miniconda is used, does it mean that not only Python but any conda package can be indicated in dependency ? And another question, do you know if miniconda is installed on testing CRAN machines? (Without this I cannot see how your packages with conda dependencies could be tested during their submission.) Best, Serguei. Similarly, rather than having this part of SystemRequirements, package authors could declare these in a separate field called e.g. Config/conda. Then, you could have an R package that knows how to read and parse these configuration requests, and install those packages for the user. That said, maintaining a Conda installation and its environments is non-trivial, and things do not always work as expected when mixing Conda applications with non-Conda applications. Most notably, Conda installations bundle their own copies of libraries; e.g. the C++ standard library, Qt, OpenSSL, and so on. If an application tries to mix and match both system-provided and Conda-provided libraries in the same process, bad things often happen. This was still the lowest-friction way forward for us with reticulate, but it's worth being aware that Conda is not a total panacea. Best, Kevin On Tue, Jan 7, 2020 at 6:50 AM Serguei Sokol wrote: Best wishes for 2020! I would like to suggest a new feature for R package management. Its aim is to enable package developers and end-users to rely on conda ( https://docs.conda.io/en/latest/ ) for managing third-party software (TPS) on major platforms: linux64, win64 and osx64. Currently, many R packages include TPS as part of them thus bloating their sizes and often duplicating files on a given system. And even when TPS is not included in an R package but is just installed on a system, it is not so obvious to get the right path to it. Sometimes pkg-config helps but it is not always present. So, the new feature would be to let R package developers to write in DESCRIPTION/SystemRequirements field something like 'conda:boost-cpp>=1.71' where 'boost-cpp' is an example of a conda package and '>=1.71' is an optional version requirement. Having this could allow install.packages() to install TPS on a testing CRAN machine or on an end-user's one. (There is just one line to execute in a shell: conda install . It will install the package itself as well as all its dependencies). To my mind, this feature would have the following advantages: - on-disk size economy as the same TPS does not have to be included in R package itself and can be shared with other language wrappers, e.g. Python; - an easy flag configuring in Makevars as paths to TPS will be well known in advance; - CRAN machines could test packages relying on a wide panel of TPS without bothering with their manual installation; - TPS installation can become transparent for the end-user on major platforms; Note that even R is part of conda ( https://anaconda.org/conda-forge/r-base ), it is not mandatory to use the conda's R version for this feature. Here, conda is just meant to facilitate access to TPS. However, a minimal requirement is obviously to have conda itself. Does it look reasonable? appealing? Best, Serguei. __ 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] rhub, docker and Bioconductor
On Tue, 7 Jan 2020 13:54:38 +
Christian Martin Hennig wrote:
> Are there any other options apart from rhub/docker to get wiser about
> my errors and issues (error on debian-clang in a routine that shows
> nothing suspicious on my machine
I cannot answer your original questions, but I can offer some advice on
the problems uncovered by package checks:
> covinv <- try(solve(m))
> if (class(covinv) != "try-error")
In R-devel, matrices are now also arrays [*]:
>> matrix objects now also inherit from class "array", namely, e.g.,
>> class(diag(1)) is c("matrix", "array") which invalidates code
>> assuming that length(class(obj)) == 1, an incorrect assumption that
>> is less frequently fulfilled now.
Use !inherits(convinv, 'try-error') instead.
> additional issues
> ATLAS
> MKL
> noLD
> OpenBLAS)?
These mostly seem to be concerned with the package startup message from
the mclust package. Try wrapping the calls to library(mclust) into
suppressPackageStartupMessages()?
As for the numbers being different between .Rout.save and actual test
results in ATLAS/MKL/noLD/OpenBLAS tests despite set.seed() being used,
I am not sure what could be done. RNGversion() might help, but this
could also be caused by differences in mclust version, in which case
the result might just be impossible to reproduce.
--
Best regards,
Ivan
[*] https://stat.ethz.ch/R-manual/R-devel/doc/html/NEWS.html
Link should be valid until R-4.0.0 is released.
__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel
Re: [R-pkg-devel] suggestion: conda for third-party software
The newest version of reticulate does something very similar: R packages can declare their Python package dependencies in the Config/reticulate field of a DESCRIPTION file, and reticulate can read and use those dependencies to provision a Python environment for the user when requested (currently using Miniconda). Similarly, rather than having this part of SystemRequirements, package authors could declare these in a separate field called e.g. Config/conda. Then, you could have an R package that knows how to read and parse these configuration requests, and install those packages for the user. That said, maintaining a Conda installation and its environments is non-trivial, and things do not always work as expected when mixing Conda applications with non-Conda applications. Most notably, Conda installations bundle their own copies of libraries; e.g. the C++ standard library, Qt, OpenSSL, and so on. If an application tries to mix and match both system-provided and Conda-provided libraries in the same process, bad things often happen. This was still the lowest-friction way forward for us with reticulate, but it's worth being aware that Conda is not a total panacea. Best, Kevin On Tue, Jan 7, 2020 at 6:50 AM Serguei Sokol wrote: > > Best wishes for 2020! > > I would like to suggest a new feature for R package management. Its aim > is to enable package developers and end-users to rely on conda ( > https://docs.conda.io/en/latest/ ) for managing third-party software > (TPS) on major platforms: linux64, win64 and osx64. Currently, many R > packages include TPS as part of them thus bloating their sizes and often > duplicating files on a given system. And even when TPS is not included > in an R package but is just installed on a system, it is not so obvious > to get the right path to it. Sometimes pkg-config helps but it is not > always present. > > So, the new feature would be to let R package developers to write in > DESCRIPTION/SystemRequirements field something like > 'conda:boost-cpp>=1.71' where 'boost-cpp' is an example of a conda > package and '>=1.71' is an optional version requirement. Having this > could allow install.packages() to install TPS on a testing CRAN machine > or on an end-user's one. (There is just one line to execute in a shell: > conda install . It will install the package itself as well as > all its dependencies). > > To my mind, this feature would have the following advantages: > - on-disk size economy as the same TPS does not have to be included in > R package itself and can be shared with other language wrappers, e.g. > Python; > - an easy flag configuring in Makevars as paths to TPS will be well > known in advance; > - CRAN machines could test packages relying on a wide panel of TPS > without bothering with their manual installation; > - TPS installation can become transparent for the end-user on major > platforms; > > Note that even R is part of conda ( > https://anaconda.org/conda-forge/r-base ), it is not mandatory to use > the conda's R version for this feature. Here, conda is just meant to > facilitate access to TPS. However, a minimal requirement is obviously to > have conda itself. > > Does it look reasonable? appealing? > Best, > Serguei. > > __ > 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] rhub, docker and Bioconductor
I was tracking down problems with my package yesterday that were specific
to r-devel and I had trouble reproducing the errors. I believe the issue is
that the rhub and the docker/rocker r-devel were not using the most recent
version of r-devel. My solution was to add r-devel to my travis ci.
https://towardsdatascience.com/travis-ci-for-r-advanced-guide-719cb2d9e0e5
This allowed me to reproduce the errors.
Brian
On Tue, Jan 7, 2020 at 6:35 AM Christian Martin Hennig <
christian.hen...@unibo.it> wrote:
> That's good to know. I'm still at a loss what to do though. How are you
> checking your packages on systems that are not available to you, other
> than using rhub?
>
> Chances are if something from Bioconductor is required by one of the
> packages that I require, I can't get rid of it, right?
>
> Thanks,
>
> Christian
>
> On 1/7/20 3:06 PM, Gábor Csárdi wrote:
> > It is an R-hub bug: https://github.com/r-hub/rhub/issues/318
> >
> > Gabor
> >
> > On Tue, Jan 7, 2020 at 2:05 PM Christian Martin Hennig
> > wrote:
> >> I should maybe add that I'm not even sure why I need Bioconductor, the
> >> package has:
> >>
> >> Imports: MASS, cluster, mclust, flexmix, prabclus, class, diptest,
> >> robustbase, kernlab, grDevices, graphics, methods, stats, utils,
> parallel
> >> Suggests: tclust, pdfCluster, EMMIXskew, mvtnorm
> >>
> >> Christian
> >>
> >> On 1/7/20 2:54 PM, Christian Martin Hennig wrote:
> >>> Hi there,
> >>>
> >>> I'm trying to track down some errors and issues of my fpc package. As
> I can't reproduce any of these on my machine, I'm using rhub and docker.
> >>>
> >>> I'm getting Bioconductor related issues with both
> >>>
> >>> local_check_linux("fpc_2.2-3.tar.gz", image =
> "rhub/debian-clang-devel")
> >>>
> >>> and
> >>>
> >>> rhub::check("fpc_2.2-3.tar.gz", platform = "debian-clang-devel")
> >>>
> >>> namely locally:
> >>>
> >>> source('https://bioconductor.org/biocLite.R')
> >>> Error: With R version 3.5 or greater, install Bioconductor packages
> using BiocManager; see https://bioconductor.org/install
> >>> Execution halted
> >>> Error in run(bash, c(file.path(wd, "rhub-linux.sh"), args), echo =
> TRUE, :
> >>> System command error
> >>>
> >>> ...and on rhub:
> >>>
> >>> 91<
> https://builder.r-hub.io/status/fpc_2.2-3.tar.gz-2492f95fc1c94fcbbff4d6f47cb423f8#L91>#>
> Error: package or namespace load failed for 'BiocManager':
> >>>
> >>> 92<
> https://builder.r-hub.io/status/fpc_2.2-3.tar.gz-2492f95fc1c94fcbbff4d6f47cb423f8#L92>#>
> .onAttach failed in attachNamespace() for 'BiocManager', details:
> >>>
> >>> 93<
> https://builder.r-hub.io/status/fpc_2.2-3.tar.gz-2492f95fc1c94fcbbff4d6f47cb423f8#L93>#>
> call: if (version[, 1:2] != version) return(sprintf("version '%s' must have
> two components, e.g., '3.7'",
> >>>
> >>> 94<
> https://builder.r-hub.io/status/fpc_2.2-3.tar.gz-2492f95fc1c94fcbbff4d6f47cb423f8#L94>#>
> error: argument is of length zero
> >>>
> >>> 95<
> https://builder.r-hub.io/status/fpc_2.2-3.tar.gz-2492f95fc1c94fcbbff4d6f47cb423f8#L95>#>
> Error: loading failed
> >>>
> >>> 96<
> https://builder.r-hub.io/status/fpc_2.2-3.tar.gz-2492f95fc1c94fcbbff4d6f47cb423f8#L96>#>
> Execution halted
> >>>
> >>> 97<
> https://builder.r-hub.io/status/fpc_2.2-3.tar.gz-2492f95fc1c94fcbbff4d6f47cb423f8#L97>#>
> ERROR: loading failed
> >>>
> >>> (To be totally honest, I'm not even sure whether the latter rhub issue
> doesn't refer to the local docker thing as well, because this was linked
> from an R-hub builder PREPERROR email, it also mentions docker, and all the
> time indications don't make it unambiguously clear to what build they
> refer.)
> >>>
> >>> Not sure what to do about this. Are there any other options apart from
> rhub/docker to get wiser about my errors and issues (error on debian-clang
> in a routine that shows nothing suspicious on my machine, additional
> issues ATLAS MKL<
> https://www.stats.ox.ac.uk/pub/bdr/Rblas/MKL/fpc.out> noLD<
> https://www.stats.ox.ac.uk/pub/bdr/noLD/fpc.out> OpenBLAS)?<
> https://www.stats.ox.ac.uk/pub/bdr/Rblas/OpenBLAS/fpc.out>
> >>>
> >>> Yesterday I was able to check a prabclus noLD error on rhub, but no
> luck yet with fpc.
> >>>
> >>> Thanks a lot,
> >>>
> >>> Christian
> >>>
> >>> --
> >>> Christian Hennig
> >>> Dipartimento di Scienze Statistiche "Paolo Fortunati",
> >>> Universita di Bologna, phone +39 05120 98163
> >>> christian.hen...@unibo.it
> >>>
> >>>[[alternative HTML version deleted]]
> >>>
> >>> __
> >>> R-package-devel@r-project.org mailing list
> >>> https://stat.ethz.ch/mailman/listinfo/r-package-devel
> >> --
> >> Christian Hennig
> >> Dipartimento di Scienze Statistiche "Paolo Fortunati",
> >> Universita di Bologna, phone +39 05120 98163
> >> christian.hen...@unibo.it
> >>
> >> __
> >> R-package-devel@r-project.org mailing list
> >> https:/
[R-pkg-devel] suggestion: conda for third-party software
Best wishes for 2020! I would like to suggest a new feature for R package management. Its aim is to enable package developers and end-users to rely on conda ( https://docs.conda.io/en/latest/ ) for managing third-party software (TPS) on major platforms: linux64, win64 and osx64. Currently, many R packages include TPS as part of them thus bloating their sizes and often duplicating files on a given system. And even when TPS is not included in an R package but is just installed on a system, it is not so obvious to get the right path to it. Sometimes pkg-config helps but it is not always present. So, the new feature would be to let R package developers to write in DESCRIPTION/SystemRequirements field something like 'conda:boost-cpp>=1.71' where 'boost-cpp' is an example of a conda package and '>=1.71' is an optional version requirement. Having this could allow install.packages() to install TPS on a testing CRAN machine or on an end-user's one. (There is just one line to execute in a shell: conda install . It will install the package itself as well as all its dependencies). To my mind, this feature would have the following advantages: - on-disk size economy as the same TPS does not have to be included in R package itself and can be shared with other language wrappers, e.g. Python; - an easy flag configuring in Makevars as paths to TPS will be well known in advance; - CRAN machines could test packages relying on a wide panel of TPS without bothering with their manual installation; - TPS installation can become transparent for the end-user on major platforms; Note that even R is part of conda ( https://anaconda.org/conda-forge/r-base ), it is not mandatory to use the conda's R version for this feature. Here, conda is just meant to facilitate access to TPS. However, a minimal requirement is obviously to have conda itself. Does it look reasonable? appealing? Best, Serguei. __ R-package-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel
Re: [R-pkg-devel] rhub, docker and Bioconductor
That's good to know. I'm still at a loss what to do though. How are you
checking your packages on systems that are not available to you, other
than using rhub?
Chances are if something from Bioconductor is required by one of the
packages that I require, I can't get rid of it, right?
Thanks,
Christian
On 1/7/20 3:06 PM, Gábor Csárdi wrote:
> It is an R-hub bug: https://github.com/r-hub/rhub/issues/318
>
> Gabor
>
> On Tue, Jan 7, 2020 at 2:05 PM Christian Martin Hennig
> wrote:
>> I should maybe add that I'm not even sure why I need Bioconductor, the
>> package has:
>>
>> Imports: MASS, cluster, mclust, flexmix, prabclus, class, diptest,
>> robustbase, kernlab, grDevices, graphics, methods, stats, utils, parallel
>> Suggests: tclust, pdfCluster, EMMIXskew, mvtnorm
>>
>> Christian
>>
>> On 1/7/20 2:54 PM, Christian Martin Hennig wrote:
>>> Hi there,
>>>
>>> I'm trying to track down some errors and issues of my fpc package. As I
>>> can't reproduce any of these on my machine, I'm using rhub and docker.
>>>
>>> I'm getting Bioconductor related issues with both
>>>
>>> local_check_linux("fpc_2.2-3.tar.gz", image = "rhub/debian-clang-devel")
>>>
>>> and
>>>
>>> rhub::check("fpc_2.2-3.tar.gz", platform = "debian-clang-devel")
>>>
>>> namely locally:
>>>
>>> source('https://bioconductor.org/biocLite.R')
>>> Error: With R version 3.5 or greater, install Bioconductor packages using
>>> BiocManager; see https://bioconductor.org/install
>>> Execution halted
>>> Error in run(bash, c(file.path(wd, "rhub-linux.sh"), args), echo = TRUE, :
>>> System command error
>>>
>>> ...and on rhub:
>>>
>>> 91#>
>>> Error: package or namespace load failed for 'BiocManager':
>>>
>>> 92#>
>>> .onAttach failed in attachNamespace() for 'BiocManager', details:
>>>
>>> 93#>
>>> call: if (version[, 1:2] != version) return(sprintf("version '%s' must
>>> have two components, e.g., '3.7'",
>>>
>>> 94#>
>>> error: argument is of length zero
>>>
>>> 95#>
>>> Error: loading failed
>>>
>>> 96#>
>>> Execution halted
>>>
>>> 97#>
>>> ERROR: loading failed
>>>
>>> (To be totally honest, I'm not even sure whether the latter rhub issue
>>> doesn't refer to the local docker thing as well, because this was linked
>>> from an R-hub builder PREPERROR email, it also mentions docker, and all the
>>> time indications don't make it unambiguously clear to what build they
>>> refer.)
>>>
>>> Not sure what to do about this. Are there any other options apart from
>>> rhub/docker to get wiser about my errors and issues (error on debian-clang
>>> in a routine that shows nothing suspicious on my machine, additional issues
>>> ATLAS
>>> MKL
>>> noLD
>>> OpenBLAS)?
>>>
>>> Yesterday I was able to check a prabclus noLD error on rhub, but no luck
>>> yet with fpc.
>>>
>>> Thanks a lot,
>>>
>>> Christian
>>>
>>> --
>>> Christian Hennig
>>> Dipartimento di Scienze Statistiche "Paolo Fortunati",
>>> Universita di Bologna, phone +39 05120 98163
>>> christian.hen...@unibo.it
>>>
>>>[[alternative HTML version deleted]]
>>>
>>> __
>>> R-package-devel@r-project.org mailing list
>>> https://stat.ethz.ch/mailman/listinfo/r-package-devel
>> --
>> Christian Hennig
>> Dipartimento di Scienze Statistiche "Paolo Fortunati",
>> Universita di Bologna, phone +39 05120 98163
>> christian.hen...@unibo.it
>>
>> __
>> R-package-devel@r-project.org mailing list
>> https://stat.ethz.ch/mailman/listinfo/r-package-devel
--
Christian Hennig
Dipartimento di Scienze Statistiche "Paolo Fortunati",
Universita di Bologna, phone +39 05120 98163
christian.hen...@unibo.it
__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel
Re: [R-pkg-devel] rhub, docker and Bioconductor
It is an R-hub bug: https://github.com/r-hub/rhub/issues/318
Gabor
On Tue, Jan 7, 2020 at 2:05 PM Christian Martin Hennig
wrote:
>
> I should maybe add that I'm not even sure why I need Bioconductor, the
> package has:
>
> Imports: MASS, cluster, mclust, flexmix, prabclus, class, diptest,
> robustbase, kernlab, grDevices, graphics, methods, stats, utils, parallel
> Suggests: tclust, pdfCluster, EMMIXskew, mvtnorm
>
> Christian
>
> On 1/7/20 2:54 PM, Christian Martin Hennig wrote:
> > Hi there,
> >
> > I'm trying to track down some errors and issues of my fpc package. As I
> > can't reproduce any of these on my machine, I'm using rhub and docker.
> >
> > I'm getting Bioconductor related issues with both
> >
> >local_check_linux("fpc_2.2-3.tar.gz", image = "rhub/debian-clang-devel")
> >
> > and
> >
> > rhub::check("fpc_2.2-3.tar.gz", platform = "debian-clang-devel")
> >
> > namely locally:
> >
> > source('https://bioconductor.org/biocLite.R')
> > Error: With R version 3.5 or greater, install Bioconductor packages using
> > BiocManager; see https://bioconductor.org/install
> > Execution halted
> > Error in run(bash, c(file.path(wd, "rhub-linux.sh"), args), echo = TRUE, :
> >System command error
> >
> > ...and on rhub:
> >
> > 91#>
> > Error: package or namespace load failed for 'BiocManager':
> >
> > 92#>
> > .onAttach failed in attachNamespace() for 'BiocManager', details:
> >
> > 93#>
> > call: if (version[, 1:2] != version) return(sprintf("version '%s' must
> > have two components, e.g., '3.7'",
> >
> > 94#>
> > error: argument is of length zero
> >
> > 95#>
> > Error: loading failed
> >
> > 96#>
> > Execution halted
> >
> > 97#>
> > ERROR: loading failed
> >
> > (To be totally honest, I'm not even sure whether the latter rhub issue
> > doesn't refer to the local docker thing as well, because this was linked
> > from an R-hub builder PREPERROR email, it also mentions docker, and all the
> > time indications don't make it unambiguously clear to what build they
> > refer.)
> >
> > Not sure what to do about this. Are there any other options apart from
> > rhub/docker to get wiser about my errors and issues (error on debian-clang
> > in a routine that shows nothing suspicious on my machine, additional issues
> > ATLAS
> > MKL
> > noLD
> > OpenBLAS)?
> >
> > Yesterday I was able to check a prabclus noLD error on rhub, but no luck
> > yet with fpc.
> >
> > Thanks a lot,
> >
> > Christian
> >
> > --
> > Christian Hennig
> > Dipartimento di Scienze Statistiche "Paolo Fortunati",
> > Universita di Bologna, phone +39 05120 98163
> > christian.hen...@unibo.it
> >
> > [[alternative HTML version deleted]]
> >
> > __
> > R-package-devel@r-project.org mailing list
> > https://stat.ethz.ch/mailman/listinfo/r-package-devel
>
> --
> Christian Hennig
> Dipartimento di Scienze Statistiche "Paolo Fortunati",
> Universita di Bologna, phone +39 05120 98163
> christian.hen...@unibo.it
>
> __
> 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] rhub, docker and Bioconductor
I should maybe add that I'm not even sure why I need Bioconductor, the
package has:
Imports: MASS, cluster, mclust, flexmix, prabclus, class, diptest,
robustbase, kernlab, grDevices, graphics, methods, stats, utils, parallel
Suggests: tclust, pdfCluster, EMMIXskew, mvtnorm
Christian
On 1/7/20 2:54 PM, Christian Martin Hennig wrote:
> Hi there,
>
> I'm trying to track down some errors and issues of my fpc package. As I can't
> reproduce any of these on my machine, I'm using rhub and docker.
>
> I'm getting Bioconductor related issues with both
>
>local_check_linux("fpc_2.2-3.tar.gz", image = "rhub/debian-clang-devel")
>
> and
>
> rhub::check("fpc_2.2-3.tar.gz", platform = "debian-clang-devel")
>
> namely locally:
>
> source('https://bioconductor.org/biocLite.R')
> Error: With R version 3.5 or greater, install Bioconductor packages using
> BiocManager; see https://bioconductor.org/install
> Execution halted
> Error in run(bash, c(file.path(wd, "rhub-linux.sh"), args), echo = TRUE, :
>System command error
>
> ...and on rhub:
>
> 91#>
> Error: package or namespace load failed for 'BiocManager':
>
> 92#>
> .onAttach failed in attachNamespace() for 'BiocManager', details:
>
> 93#>
> call: if (version[, 1:2] != version) return(sprintf("version '%s' must have
> two components, e.g., '3.7'",
>
> 94#>
> error: argument is of length zero
>
> 95#>
> Error: loading failed
>
> 96#>
> Execution halted
>
> 97#>
> ERROR: loading failed
>
> (To be totally honest, I'm not even sure whether the latter rhub issue
> doesn't refer to the local docker thing as well, because this was linked from
> an R-hub builder PREPERROR email, it also mentions docker, and all the time
> indications don't make it unambiguously clear to what build they refer.)
>
> Not sure what to do about this. Are there any other options apart from
> rhub/docker to get wiser about my errors and issues (error on debian-clang in
> a routine that shows nothing suspicious on my machine, additional issues
> ATLAS
> MKL
> noLD
> OpenBLAS)?
>
> Yesterday I was able to check a prabclus noLD error on rhub, but no luck yet
> with fpc.
>
> Thanks a lot,
>
> Christian
>
> --
> Christian Hennig
> Dipartimento di Scienze Statistiche "Paolo Fortunati",
> Universita di Bologna, phone +39 05120 98163
> christian.hen...@unibo.it
>
> [[alternative HTML version deleted]]
>
> __
> R-package-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-package-devel
--
Christian Hennig
Dipartimento di Scienze Statistiche "Paolo Fortunati",
Universita di Bologna, phone +39 05120 98163
christian.hen...@unibo.it
__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel
[R-pkg-devel] rhub, docker and Bioconductor
Hi there,
I'm trying to track down some errors and issues of my fpc package. As I can't
reproduce any of these on my machine, I'm using rhub and docker.
I'm getting Bioconductor related issues with both
local_check_linux("fpc_2.2-3.tar.gz", image = "rhub/debian-clang-devel")
and
rhub::check("fpc_2.2-3.tar.gz", platform = "debian-clang-devel")
namely locally:
>
source('https://bioconductor.org/biocLite.R')
Error: With R version 3.5 or greater, install Bioconductor packages using
BiocManager; see https://bioconductor.org/install
Execution halted
Error in run(bash, c(file.path(wd, "rhub-linux.sh"), args), echo = TRUE, :
System command error
...and on rhub:
91#>
Error: package or namespace load failed for 'BiocManager':
92#>
.onAttach failed in attachNamespace() for 'BiocManager', details:
93#>
call: if (version[, 1:2] != version) return(sprintf("version '%s' must have
two components, e.g., '3.7'",
94#>
error: argument is of length zero
95#>
Error: loading failed
96#>
Execution halted
97#>
ERROR: loading failed
(To be totally honest, I'm not even sure whether the latter rhub issue doesn't
refer to the local docker thing as well, because this was linked from an R-hub
builder PREPERROR email, it also mentions docker, and all the time indications
don't make it unambiguously clear to what build they refer.)
Not sure what to do about this. Are there any other options apart from
rhub/docker to get wiser about my errors and issues (error on debian-clang in a
routine that shows nothing suspicious on my machine, additional issues
ATLAS
MKL
noLD
OpenBLAS)?
Yesterday I was able to check a prabclus noLD error on rhub, but no luck yet
with fpc.
Thanks a lot,
Christian
--
Christian Hennig
Dipartimento di Scienze Statistiche "Paolo Fortunati",
Universita di Bologna, phone +39 05120 98163
christian.hen...@unibo.it
[[alternative HTML version deleted]]
__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel
