Re: [Bioc-devel] unix package in suggest leads to check error

[Alexey Sergushichev]

Hi Herve,

We don't have tests for this part in the package tests (we have separate
integration tests for that), but the full package functionality depends on
bringing up an opencpu server, which uses the unix package to evaluate
HTTP-requests within R environment. The servePhantasus function, which
starts opencpu server, doesn't work properly on a Linux machine without
unix package.

On the other hand, now I'm thinking that "suggests" is not the best way for
that package either, as it's really a proper dependency on linux systems. I
guess we'll just a code to check for the presence of the package in the
corresponding functions.

--
Alexey

On Fri, Apr 19, 2024 at 2:18 PM Hervé Pagès 
wrote:

> Hi Alex,
> On 4/19/24 09:53, Alexey Sergushichev wrote:
>
> Hi,
>
> Our package "phantasus" requires the "unix" package to properly work on
> *nix systems,
>
> I just tried to run 'R CMD check' on phantasus on my Linux laptop where I
> don't have the unix package installed, and everything went fine. In
> particular all the examples and unit tests passed with no problem. So I'm
> not sure what you mean when you say that the unix package is required for 
> phantasus
> "to properly work".
>
> So unless I'm missing something, I see no reason to list unix in the
> Suggests field of your package.
>
> Best,
>
> H.
>
>  but works well without it on Windows and Mac OS (actually we
> depend on the opencpu package, which requires it). I've tried to put this
> package into suggest field, but now the package failed Bioc checks on
> Windows and Mac 
> (https://bioconductor.org/checkResults/devel/bioc-LATEST/phantasus/palomino3-checksrc.html)
> with the following message:
>
> ```
> * checking package dependencies ... ERROR
> Package suggested but not available: 'unix'
>
> The suggested packages are required for a complete check.
> Checking can be attempted without them by setting the environment
> variable _R_CHECK_FORCE_SUGGESTS_ to a false value.
> ```
>
> Is there any way to keep this package in suggestions and not to fail the
> checks? Or are there any other recommendations for this case?
>
> Best,
> Alexey
>
>   [[alternative HTML version deleted]]
>
> ___bioc-de...@r-project.org 
> mailing listhttps://stat.ethz.ch/mailman/listinfo/bioc-devel
>
> --
> Hervé Pagès
>
> Bioconductor Core teamhpages.on.git...@gmail.com
>
>

[[alternative HTML version deleted]]

___
Bioc-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/bioc-devel

[Bioc-devel] unix package in suggest leads to check error

[Alexey Sergushichev]

Hi,

Our package "phantasus" requires the "unix" package to properly work on
*nix systems, but works well without it on Windows and Mac OS (actually we
depend on the opencpu package, which requires it). I've tried to put this
package into suggest field, but now the package failed Bioc checks on
Windows and Mac (
https://bioconductor.org/checkResults/devel/bioc-LATEST/phantasus/palomino3-checksrc.html)
with the following message:

```
* checking package dependencies ... ERROR
Package suggested but not available: 'unix'

The suggested packages are required for a complete check.
Checking can be attempted without them by setting the environment
variable _R_CHECK_FORCE_SUGGESTS_ to a false value.
```

Is there any way to keep this package in suggestions and not to fail the
checks? Or are there any other recommendations for this case?

Best,
Alexey

[[alternative HTML version deleted]]

___
Bioc-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/bioc-devel

Re: [Bioc-devel] Not receiving original posts for watched tags at bioconductor support

[Alexey Sergushichev]

Lori, thanks! Didn't think about searching on github to check whether this
issue was already reported. Hope it will get resolved.

--
Alexey

On Thu, Sep 28, 2023 at 6:16 AM Kern, Lori 
wrote:

> There was some issue posted here:
> https://github.com/Bioconductor/support.bioconductor.org/issues/78
>
> We are aware of the issue of not being emailed on the first post and are
> actively looking into a fix for it.
>
> Thank you for letting us know.
>
>
> Lori Shepherd - Kern
>
> Bioconductor Core Team
>
> Roswell Park Comprehensive Cancer Center
>
> Department of Biostatistics & Bioinformatics
>
> Elm & Carlton Streets
>
> Buffalo, New York 14263
> --
> *From:* Bioc-devel  on behalf of Lluís
> Revilla 
> *Sent:* Wednesday, September 27, 2023 7:39 PM
> *To:* Alexey Sergushichev 
> *Cc:* bioc-devel 
> *Subject:* Re: [Bioc-devel] Not receiving original posts for watched tags
> at bioconductor support
>
> Hi,
>
> While checking this, I realized that
>
> https://secure-web.cisco.com/18IGkeFBtjVa4TYb0Y9OwgM6Bjyw38MHFoitbHayY7UWvGkolpQU6FqGFF6bQMV1qKGNHz9T7Coi1Acxo5UdxtGlPmPdmwBcXMpUK7ykbFcxFSzmWshFATVSNDmSygNRH4X5jNyLyydkorn0_LIEtQLpMv1tavlxcMo8TD-DaFVIar6s2Ih3NC2WNcAoM6OnMdlxYKLXC_Vu6TWKbRuIpJt6gMO1HxPpSJJ1amL9lcMK5VFf4AOQMUIdsLQA49DN73LoFBxPudsGLW6Ni7h_kf-vzO5Hho3GcyBGH5neIlmCts-OR_I07bvhjRQL_opPO/https%3A%2F%2Fsupport.bioconductor.org%2Fmytags%2F
> doesn't show the tags I have in my
> profile as "My Tags" and as "Watched Tags".
> Not sure if it is related.
>
> Best,
>
> Lluís
>
> On Thu, 28 Sept 2023 at 01:00, Alexey Sergushichev 
> wrote:
>
> > Hi,
> >
> > I have a problem that I only receive e-mail notifications from
> > support.bioconductor.org for my watched tags (e.g. "fgsea") with the
> > answers and comments but not for the post itself. So I never learn about
> > the unanswered questions unless I go directly to
> >
> https://secure-web.cisco.com/18IGkeFBtjVa4TYb0Y9OwgM6Bjyw38MHFoitbHayY7UWvGkolpQU6FqGFF6bQMV1qKGNHz9T7Coi1Acxo5UdxtGlPmPdmwBcXMpUK7ykbFcxFSzmWshFATVSNDmSygNRH4X5jNyLyydkorn0_LIEtQLpMv1tavlxcMo8TD-DaFVIar6s2Ih3NC2WNcAoM6OnMdlxYKLXC_Vu6TWKbRuIpJt6gMO1HxPpSJJ1amL9lcMK5VFf4AOQMUIdsLQA49DN73LoFBxPudsGLW6Ni7h_kf-vzO5Hho3GcyBGH5neIlmCts-OR_I07bvhjRQL_opPO/https%3A%2F%2Fsupport.bioconductor.org%2Fmytags%2F
> Does anyone else have this
> > problem?
> >
> > Best,
> > Alexey
> >
> > [[alternative HTML version deleted]]
> >
> > ___
> > Bioc-devel@r-project.org mailing list
> >
> https://secure-web.cisco.com/1Ap-RD8a1iVYfTbCfhr5SB0o5Fx5eyJN1VRSdkRZATqxLOZlkkQ7FJF6LUj-mRFiuv3xjcSkMD2kg_EPjyHmjBKJ0A3hjNkFPpOnTy16Up5QdY0VgDmnbagv1Tuxb45C6B3eqMnpYh0lsNeyxc34e8Ia9ODKzNVLXw11me8LfLjH-4mOYx0Iu6TFXIQ3YbBsrUwwZLpg34_v8hTUp413AFODzt45l6wf0J-myabLsLoXs_uV1Hp_-mS5vxR2w4u4qcJ8jyZoNOVSP78VPCkEo7oyJ6WRI9CePNpAb320hAlAQX50mCN46BBa6CH7LwFaZ/https%3A%2F%2Fstat.ethz.ch%2Fmailman%2Flistinfo%2Fbioc-devel
> >
>
> [[alternative HTML version deleted]]
>
> ___
> Bioc-devel@r-project.org mailing list
>
> https://secure-web.cisco.com/1Ap-RD8a1iVYfTbCfhr5SB0o5Fx5eyJN1VRSdkRZATqxLOZlkkQ7FJF6LUj-mRFiuv3xjcSkMD2kg_EPjyHmjBKJ0A3hjNkFPpOnTy16Up5QdY0VgDmnbagv1Tuxb45C6B3eqMnpYh0lsNeyxc34e8Ia9ODKzNVLXw11me8LfLjH-4mOYx0Iu6TFXIQ3YbBsrUwwZLpg34_v8hTUp413AFODzt45l6wf0J-myabLsLoXs_uV1Hp_-mS5vxR2w4u4qcJ8jyZoNOVSP78VPCkEo7oyJ6WRI9CePNpAb320hAlAQX50mCN46BBa6CH7LwFaZ/https%3A%2F%2Fstat.ethz.ch%2Fmailman%2Flistinfo%2Fbioc-devel
>
>
> This email message may contain legally privileged and/or confidential
> information. If you are not the intended recipient(s), or the employee or
> agent responsible for the delivery of this message to the intended
> recipient(s), you are hereby notified that any disclosure, copying,
> distribution, or use of this email message is prohibited. If you have
> received this message in error, please notify the sender immediately by
> e-mail and delete this email message from your computer. Thank you.
>

[[alternative HTML version deleted]]

___
Bioc-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/bioc-devel

[Bioc-devel] Not receiving original posts for watched tags at bioconductor support

[Alexey Sergushichev]

Hi,

I have a problem that I only receive e-mail notifications from
support.bioconductor.org for my watched tags (e.g. "fgsea") with the
answers and comments but not for the post itself. So I never learn about
the unanswered questions unless I go directly to
https://support.bioconductor.org/mytags/ Does anyone else have this
problem?

Best,
Alexey

[[alternative HTML version deleted]]

___
Bioc-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/bioc-devel

[Rd] Incorrect behavior of ks.test and psmirnov functions with exact=TRUE

[Alexey Sergushichev]

HI,

I've noticed what I think is an incorrect behavior of stats::psmirnov
function and consequently of ks.test when run in an exact mode.

For example:
psmirnov(1, sizes=c(50, 50), z=1:100, two.sided = FALSE, lower.tail = F,
exact=TRUE)

produces 2.775558e-15

However, the exact value should be 1/combination(100, 50), which is
9.9e-30. While the absolute error is small, the relative error is huge, and
it is not fixed by setting option log.p=T

To compare, SciPy has a correct implementation in scipy.stats.ks_2samp:
scipy.stats.ks_2samp(list(range(1,51)), list(range(51, 101)),
alternative="greater", method="exact")
returns 9.911653021418333e-30.

I've tried to dig in a bit and the problem comes down to how the final
value is calculated in psmirnov function:

if (log.p & !lower.tail)
return(log1p(-ret/exp(logdenom)))
if (!log.p & !lower.tail)
return(1 - ret/exp(logdenom))

There exp(logdenom) is a relatively good (but not perfect) approximation of
combination(100, 50) = 1.008913e+29, ret is also a good approximation of
combination(100, 50)-1 = 1.008913e+29 but there is not enough double
precision for 1 - ret/exp(logdenom) to capture 1/combination(100, 50).

I don't have time to provide a fix, at least not now, but I think this
behavior (good absolute error, but poor relative error for small values)
should at least be mentioned in the manual of the methods psmirnov and/or
ks.test

Best,
Alexey Sergushichev

[[alternative HTML version deleted]]

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

Re: [Bioc-devel] GEOquery run into problem with Sys.setenv("VROOM_CONNECTION_SIZE")

[Alexey Sergushichev]

Hi,

This issue was fixed by Sean Davis in 2.63.1 (
https://github.com/seandavi/GEOquery/commit/08ff9c3524) and I believe he
has back-ported it into 2.62.1 as well. So you can install the latest
version and try again.

Best,
Alexey

On Wed, Dec 1, 2021 at 11:06 PM array chip via Bioc-devel <
bioc-devel@r-project.org> wrote:

> Hi, I a using GEOquery to download some microarray datasets. It worked
> previously without any problem under old R version (3.5 probably), but now
> run into problem now I've updated R to version 4.0.5.
>
>
> library(GEOquery)
> gse<-getGEO(GEO="GSE137140")
>
> # Found 1 file(s)
> # GSE137140_series_matrix.txt.gz
> # trying URL '
> https://ftp.ncbi.nlm.nih.gov/geo/series/GSE137nnn/GSE137140/matrix/GSE137140_series_matrix.txt.gz
> '
> # Content type 'application/x-gzip' length 45700106 bytes (43.6 MB)
> # downloaded 43.6 MB
>
> # Error: The size of the connection biffer (131072) was not large enough
> # to fit a complete line:
> #Increase it by setting 'Sys.setenv("VROOM_CONNECTION_SIZE")'
>
> sessionInfo( )
>
> R version 4.0.5 (2021-03-31)
> Platform: x86_64-w64-mingw32/x64 (64-bit)
> Running under: Windows 10 x64 (build 19042)
>
> Matrix products: default
>
> locale:
> [1] LC_COLLATE=English_United States.1252  LC_CTYPE=English_United
> States.1252LC_MONETARY=English_United States.1252
> [4] LC_NUMERIC=C   LC_TIME=English_United
> States.1252
>
> attached base packages:
> [1] parallel  stats graphics  grDevices utils datasets  methods
> base
>
> other attached packages:
> [1] limma_3.46.0GEOquery_2.58.0
> Biobase_2.50.0  BiocGenerics_0.36.1 BiocManager_1.30.12
>
> loaded via a namespace (and not attached):
> [1] xml2_1.3.3   magrittr_2.0.1
> hms_1.1.1bit_4.0.4tidyselect_1.1.1 R6_2.5.1
> rlang_0.4.12 fansi_0.5.0
> [9] dplyr_1.0.7  tools_4.0.5  vroom_1.5.7  utf8_1.2.2
> DBI_1.1.1withr_2.4.3  ellipsis_0.3.2   bit64_4.0.5
> [17] assertthat_0.2.1 tibble_3.1.6 lifecycle_1.0.1  crayon_1.4.2
> tidyr_1.1.4  purrr_0.3.4  readr_2.1.1  tzdb_0.2.0
> [25] vctrs_0.3.8  curl_4.3.2   glue_1.5.1   compiler_4.0.5
> pillar_1.6.4 generics_0.1.1   pkgconfig_2.0.3
>
>
> I tried to increase the connection buffer by
> Sys.setenv("VROOM_CONNECTION_SIZE"=131072*5), but no success.
>
> Can someone tell me what's going on? Why it worked flawlessly, but now the
> problem with new R and new bioconductor versions?
>
> Thanks,
>
> John
>
> ___
> Bioc-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/bioc-devel
>

[[alternative HTML version deleted]]

___
Bioc-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/bioc-devel

Re: [Bioc-devel] List of Deprecated Packages for Bioc3.12

[Alexey Sergushichev]

Hi,

I'm interested in keeping BioNet package being available in Bioconductor.
Is it possible to make me a substitute maintainer? I think I've fixed the
build errors here: https://github.com/assaron/BioNet

Best,
Alexey



On Thu, Sep 3, 2020 at 4:39 PM Shepherd, Lori 
wrote:

> Please see the support site post for the current list of deprecated
> packages for release 3.12.  These packages will be removed from Bioc3.13.
>
> It should be noted, we did try to reach out to these package maintainers
> multiple times and they were either unresponsive or had emails bounce. We
> encourage anyone that is familiar with a package maintainer on this list to
> reach out to them and notify them directly. Packages can be un-deprecated
> if a maintainer fixes the package to build/check cleanly before the next
> release and requests un-deprecation on the bioc-devel@r-project.org
> mailing list.
>
> https://support.bioconductor.org/p/133699/
>
> Thank you
>
>
> Lori Shepherd
>
> Bioconductor Core Team
>
> Roswell Park Comprehensive Cancer Center
>
> Department of Biostatistics & Bioinformatics
>
> Elm & Carlton Streets
>
> Buffalo, New York 14263
>
>
> This email message may contain legally privileged and/or confidential
> information.  If you are not the intended recipient(s), or the employee or
> agent responsible for the delivery of this message to the intended
> recipient(s), you are hereby notified that any disclosure, copying,
> distribution, or use of this email message is prohibited.  If you have
> received this message in error, please notify the sender immediately by
> e-mail and delete this email message from your computer. Thank you.
> [[alternative HTML version deleted]]
>
> ___
> Bioc-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/bioc-devel
>

[[alternative HTML version deleted]]

___
Bioc-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/bioc-devel

Re: [Bioc-devel] Issue Reproducing BioC 3.11 COHCAP Error Message

[Alexey Sergushichev]

I think one of the major changes recently is setting stringsAsFactors
option to FALSE by default.

Best,
Alexey

On Fri, Mar 20, 2020 at 12:48 AM Charles Warden  wrote:

> Hi Lori,
>
> Thank you very much.
>
> If I use R-4.0 (instead of R-3.6), then I can reproduce the error message.
>
> I will work in figuring out why the code works with R-3.6 but not R-4.0,
> but it seems like this might affect other packages as well (since I
> received error messages for 2 out of 2 of the Bioconductor packages that I
> contributed to).
>
> Do you have any general suggestions of what types of new errors might be
> encountered from using R-4.0?
>
> Thanks Again,
> Charles
>
> From: Shepherd, Lori [mailto:lori.sheph...@roswellpark.org]
> Sent: Thursday, March 19, 2020 1:41 PM
> To: bioc-devel@r-project.org; Charles Warden 
> Subject: Re: Issue Reproducing BioC 3.11 COHCAP Error Message
>
> Yes that is the correct version of R to use. Thank you for taking the time
> to make sure everything is correct to debug. We appreciate your effort and
> contributors to bioconductor.
> Get Outlook for Android<
> https://urldefense.com/v3/__https:/aka.ms/ghei36__;!!Fou38LsQmgU!5kLQzxLFDLkE15tideOn6Lfj4ouKaT1CB36y5FZreJ7HHHtZgHjVns3uz4qi$
> >
>
> 
> From: Charles Warden mailto:cwar...@coh.org>>
> Sent: Thursday, March 19, 2020 4:37:52 PM
> To: Shepherd, Lori  lori.sheph...@roswellpark.org>>; bioc-devel@r-project.org bioc-devel@r-project.org>  bioc-devel@r-project.org>>
> Subject: RE: Issue Reproducing BioC 3.11 COHCAP Error Message
>
>
> Hi Lori,
>
>
>
> Thank you very much for your response.
>
>
>
> I was testing building the Bioconductor development branch, but I was
> using R-3.6.
>
>
>
> On the Ubuntu server where I have all the necessary dependencies
> configured, I tested compiling R-devel but it didn't exactly say R-4.0.
>
>
>
> So, in order to see if I can reproduce the error, I want to make sure I am
> using the same version of R:
>
>
>
> On the R website, it says "R version 4.0.0 (Arbor Day) prerelease versions<
> https://urldefense.com/v3/__http:/cran.r-project.org/src/base-prerelease__;!!Fou38LsQmgU!5kLQzxLFDLkE15tideOn6Lfj4ouKaT1CB36y5FZreJ7HHHtZgHjVnoU6OsCs$>
> will appear starting Tuesday 2020-03-24. Final release is scheduled for
> Friday 2020-04-24.", but I can download prerelease files from the following
> page:
>
>
>
> https://cran.r-project.org/src/base-prerelease/<
> https://urldefense.com/v3/__https:/cran.r-project.org/src/base-prerelease/__;!!Fou38LsQmgU!5kLQzxLFDLkE15tideOn6Lfj4ouKaT1CB36y5FZreJ7HHHtZgHjVng8C2GTW$
> >
>
>
>
> I tested compiling the R-devel.tar.gz file.  I think that completed
> without errors, but the version of R is reported as "R Under development
> (unstable) (2020-03-18 r78002)".  So, I am not sure if this is correct.
>
>
>
> Is this the correct version of R to try and reproduce the error on my own
> computer?  If not, can you please describe which file I should be using?  I
> would like to install this separately from R 3.6 (in case the version of R
> affects other packages as well).
>
>
>
> Thank You,
>
> Charles
>
>
>
> From: Shepherd, Lori [mailto:lori.sheph...@roswellpark.org]
> Sent: Thursday, March 19, 2020 10:48 AM
> To: Charles Warden mailto:cwar...@coh.org>>;
> bioc-devel@r-project.org
> Subject: Re: Issue Reproducing BioC 3.11 COHCAP Error Message
>
>
>
> It is not okay to ignore the emails you are getting.  You need to
> investigate to find out if the ERROR is from your package or a package you
> depend on.  While you have not made changes to the package, R has made a
> lot of changes to its base code that have broken a lot of packages.  Most
> of the changes are being documented here
>
>
>
> http://bioconductor.org/developers/how-to/troubleshoot-build-report/<
> https://urldefense.com/v3/__http:/bioconductor.org/developers/how-to/troubleshoot-build-report/__;!!Fou38LsQmgU!4jcx-leaLxfL2BEkbrsoQOxva2TZNrP3V15LcW-qR2EyDhkfpykALMS8EdUs$
> >
>
>
>
>
>
> Please remember that your github version of the repo is different than our
> bioconductor git.bioconductor.org server.
>
> http://bioconductor.org/developers/how-to/git/<
> https://urldefense.com/v3/__http:/bioconductor.org/developers/how-to/git/__;!!Fou38LsQmgU!4jcx-leaLxfL2BEkbrsoQOxva2TZNrP3V15LcW-qR2EyDhkfpykALKJUJjjp$
> >
>
> http://bioconductor.org/developers/how-to/git/sync-existing-repositories/<
> https://urldefense.com/v3/__http:/bioconductor.org/developers/how-to/git/sync-existing-repositories/__;!!Fou38LsQmgU!4jcx-leaLxfL2BEkbrsoQOxva2TZNrP3V15LcW-qR2EyDhkfpykALF7NFkcT$
> >
>
>
>
> I can reproduce this locally on my computer.  You will need to be using R
> 4.0  and Bioc 3.11 version of packages.
>
>
>
> I ran R CMD Sweave COHCAP.Rnw to produce the R code in COHCAP.R
>
>
>
>
>
> > library(COHCAP)
>
> Loading required package: WriteXLS
>
> Loading required package: COHCAPanno
>
> Loading required package: RColorBrewer
>
> Loading required package: gplots
>
>
>
> 

Re: [Bioc-devel] support the stable version of R

[Alexey Sergushichev]

Martin,

> Having said that, I'll note that specifying R as a dependency, and a
version of R as a criterion for your package, is really a mis-nomer for a
Bioconductor package -- of course it uses R, and the version of R in use
determines the Bioconductor version(s) that can be used! So a rational
change is to remove R and its version requirement from the DESCRIPTION file
entirely, a strategy taken by I think about 400 of our 1650+ packages.

Oh, it's actually an option not to include an R dependency at all. I find
it non-obvious, given the warning message that suggest to change the
version dependency to R-devel, not mentioning that omitting dependency will
fix the warning too. Should it be put somewhere in BiocCheck message?

Also, given that, I find it even more strange to have such R requirement in
BiocCheck. You are either allowed very strict dependency: R >= R-devel or
very lenient (not specifying any), but nothing in the middle.

Best,
Alexey



On Tue, Jan 15, 2019 at 3:03 AM Martin Morgan 
wrote:

> Maybe a little more helpfully, I think you should create a branch for
> 'before' Bioconductor, where you can specify R version dependency as you
> see fit.
>
> Indeed, at each release the version of your package at
> git.bioconductor.org will have a branch created for that release, e.g.,
> the RELEASE_3_8 branch, and you will want to sync that branch with your
> github repository as outlined in step 10 of
> https://bioconductor.org/developers/how-to/git/sync-existing-repositories/
> .
>
> A conscientious developer would take the opportunity to increment the
> version dependency of R in the master branch to the version of R in use in
> the devel builds of Bioconductor.
>
> Martin
>
> On 1/14/19, 5:40 PM, "Bioc-devel on behalf of Lulu Chen" <
> bioc-devel-boun...@r-project.org on behalf of luluc...@vt.edu> wrote:
>
> Dear all,
>
> When submitting package to bioconductor, it is required to change R
> version
> in "Depends" to be >= the develop version (3.6) . As my package is also
> available in GitHub, someone asks if it be possible to make it
> available
> with the stable version of R (R3.5). In fact, my package can work well
> with
> R3.5 if I change "Depends" back to R(>=3.5) .
>
> So I hope to support R3.5 for the moment before next release. Should I
> create another repository? Can I use a branch to support R3.5?
>
> Thanks,
> Lulu
>
> [[alternative HTML version deleted]]
>
> ___
> Bioc-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/bioc-devel
>
> ___
> Bioc-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/bioc-devel
>

[[alternative HTML version deleted]]

___
Bioc-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/bioc-devel

Re: [Bioc-devel] R version check in BiocChech

[Alexey Sergushichev]

> It _is_ the developer's choice.  But a developer of packages for the
Bioconductor
> project commits to using R-devel during certain pre-release phases,
depending
> on proximity in time to a point release of R.  (See
http://bioconductor.org/developers/how-to/useDevel/)
> for full details.)  BiocCheck verifies that this commitment is met.

No, BiocCheck doesn't verify this, it just checks for presence of
dependence on R >= 3.5. It actually doesn't check, whether I have installed
it on my computer at all; or how often I'm updating R-devel and test my
package against it; or whether I do some manual tests, as unit tests are
running regularly by BioConductor automatically.

--
Alexey



On Mon, Feb 19, 2018 at 9:03 PM, Vincent Carey <st...@channing.harvard.edu>
wrote:

>
>
> On Mon, Feb 19, 2018 at 11:27 AM, Alexey Sergushichev <alserg...@gmail.com
> > wrote:
>
>> Kevin,
>>
>> > It does not request users to make R-devel a _requirement_ of their
>> package.
>>
>> Sadly it does for new packages. New packages submitted to Bioconductor 3.7
>> are _required_ to have R >= 3.5 dependency, otherwist BiocCheck will
>> result
>> in a warning (
>> https://github.com/Bioconductor/BiocCheck/blob/be9cd6e36d95f
>> 8bf873b52427d2a97fce6fbb9b9/R/checks.R#L23)
>> and warnings aren't allowed for new package submission.
>>
>> > Here, I think the decision here boils down to how far back in terms of R
>> versions the developer is willing to support the package. I suppose one
>> could state R≥2.3 if they're confident about it.
>>
>> That's the problem: this is true for packages already in Bioconductor, but
>> it's not ture for the new package submissions.
>>
>> Aaron,
>>
>> > Personally, I haven't found it to be particularly difficult to update R,
>> > or to run R-devel in parallel with R 3.4, even without root privileges.
>>
>> I find it much harder for a normal user to install R-devel (and update it
>> properly, because it's a development version) and running
>> 'devtools::install_github("blabla/my_package")'.
>>
>> > I think many people underappreciate the benefits of moving to the latest
>> > version of R.
>>
>> Don't you think it should be a developer's choice whether to use such new
>> features or ignore them and have a potentially bigger audience?
>>
>
> It _is_ the developer's choice.  But a developer of packages for the
> Bioconductor
> project commits to using R-devel during certain pre-release phases,
> depending
> on proximity in time to a point release of R.  (See
> http://bioconductor.org/developers/how-to/useDevel/)
> for full details.)  BiocCheck verifies that this commitment is met.
>
>
>>
>> > Enforcing version consistency avoids heartache during release and
>> > debugging.
>>
>> But it's a developer's heartache. As I said, it even can't be attributed
>> to
>> Bioconductor at all, as it's not possible to install the package from
>> bioc-devel, unless you have the corresponding R version.
>>
>>
>> --
>> Alexey
>>
>>
>>
>> On Mon, Feb 19, 2018 at 6:38 PM, Aaron Lun <a...@wehi.edu.au> wrote:
>>
>> > I'll just throw in my two cents here.
>> >
>> > I think many people underappreciate the benefits of moving to the latest
>> > version of R. If you inspect the R-devel NEWS file, there's a couple of
>> > nice fixes/features that a developer might want to take advantage of:
>> >
>> > - sum() doesn't give NAs upon integer overflow anymore.
>> > - New ...elt(n) and ...length() functions for dealing with ellipses.
>> > - ALTREP support for 1:n sequences (wow!)
>> > - zero length subassignment in a non-zero index fails correctly.
>> >
>> > The previous 3.4.0 release also added support for more DLLs being loaded
>> > at once, which was otherwise causing headaches in workflows. And 3.4.2
>> > had a bug fix to LAPACK, which did result in a few user-level changes in
>> > some packages like edgeR. So there are considerable differences between
>> > the versions of R, especially if one is a package developer.
>> >
>> > Enforcing version consistency avoids heartache during release and
>> > debugging. There's a choice between users getting annoyed about having
>> > to update R, and then updating R, and everything working as a result; or
>> > everyone (developers/users) wasting some time figuring out whether a bug
>> > in a package is due to the code in the package itself or the version of
>> > R. The brief anno

Re: [Bioc-devel] rsvg on mac

[Alexey Sergushichev]

Valerie, thanks. Will try to ask there.

However, after looking through the mailing list it looks like R-devel
builds for OS X aren't trivial and aren't part of CRAN...

--
Alexey

On Mon, Feb 19, 2018 at 9:05 PM, Obenchain, Valerie <
valerie.obench...@roswellpark.org> wrote:

> Hi,
>
> There has been some discussion of the devel Mac binaries on the R-SIG-Mac
> mailing list. That list would be the best place to ask this question.
>
> https://stat.ethz.ch/pipermail/r-sig-mac/2018-January/thread.html
>
> Valerie
>
>
>
> On 02/19/2018 08:32 AM, Alexey Sergushichev wrote:
>
> Valerie,
>
> Are there any estimates on how often CRAN OS X builds happen? There are
> still no builds for rsvg and other packages...
>
> Thanks,
> Alexey
>
> On Wed, Feb 7, 2018 at 8:09 PM, Obenchain, Valerie <Valerie.Obenchain@
> roswellpark.org> wrote:
>
>> Hi Kevin,
>>
>> CRAN binaries for El Capitan in devel aren't available. You can see this
>> on the rsvg landing page:
>>
>> https://cran.r-project.org/web/packages/rsvg/index.html
>>
>> Nothing we can do until CRAN makes them available.
>>
>> Valerie
>>
>>
>> On 02/07/2018 08:29 AM, Kevin Horan wrote:
>>
>>
>> The ChemmineR build is failing on the mac due to a new dependency not
>> being available, the package "rsvg". Would it be possible to install
>> that on the mac build machine? Thanks.
>>
>> http://bioconductor.org/checkResults/devel/bioc-LATEST/
>> ChemmineR/merida2-install.html
>>
>>
>> Kevin
>>
>> ___
>> Bioc-devel@r-project.org<mailto:Bioc-devel@r-project.org> mailing list
>> https://stat.ethz.ch/mailman/listinfo/bioc-devel
>>
>>
>>
>>
>>
>> This email message may contain legally privileged and/or confidential
>> information.  If you are not the intended recipient(s), or the employee or
>> agent responsible for the delivery of this message to the intended
>> recipient(s), you are hereby notified that any disclosure, copying,
>> distribution, or use of this email message is prohibited.  If you have
>> received this message in error, please notify the sender immediately by
>> e-mail and delete this email message from your computer. Thank you.
>> [[alternative HTML version deleted]]
>>
>> ___
>> Bioc-devel@r-project.org mailing list
>> https://stat.ethz.ch/mailman/listinfo/bioc-devel
>>
>
>
>
> This email message may contain legally privileged and/or confidential
> information. If you are not the intended recipient(s), or the employee or
> agent responsible for the delivery of this message to the intended
> recipient(s), you are hereby notified that any disclosure, copying,
> distribution, or use of this email message is prohibited. If you have
> received this message in error, please notify the sender immediately by
> e-mail and delete this email message from your computer. Thank you.
>

[[alternative HTML version deleted]]

___
Bioc-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/bioc-devel

Re: [Bioc-devel] rsvg on mac

[Alexey Sergushichev]

Valerie,

Are there any estimates on how often CRAN OS X builds happen? There are
still no builds for rsvg and other packages...

Thanks,
Alexey

On Wed, Feb 7, 2018 at 8:09 PM, Obenchain, Valerie <
valerie.obench...@roswellpark.org> wrote:

> Hi Kevin,
>
> CRAN binaries for El Capitan in devel aren't available. You can see this
> on the rsvg landing page:
>
> https://cran.r-project.org/web/packages/rsvg/index.html
>
> Nothing we can do until CRAN makes them available.
>
> Valerie
>
>
> On 02/07/2018 08:29 AM, Kevin Horan wrote:
>
>
> The ChemmineR build is failing on the mac due to a new dependency not
> being available, the package "rsvg". Would it be possible to install
> that on the mac build machine? Thanks.
>
> http://bioconductor.org/checkResults/devel/bioc-LATEST/ChemmineR/merida2-
> install.html
>
>
> Kevin
>
> ___
> Bioc-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/bioc-devel
>
>
>
>
>
> This email message may contain legally privileged and/or confidential
> information.  If you are not the intended recipient(s), or the employee or
> agent responsible for the delivery of this message to the intended
> recipient(s), you are hereby notified that any disclosure, copying,
> distribution, or use of this email message is prohibited.  If you have
> received this message in error, please notify the sender immediately by
> e-mail and delete this email message from your computer. Thank you.
> [[alternative HTML version deleted]]
>
> ___
> Bioc-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/bioc-devel
>

[[alternative HTML version deleted]]

___
Bioc-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/bioc-devel

Re: [Bioc-devel] R version check in BiocChech

[Alexey Sergushichev]

*R*
> that
> > will be available to users when the *Bioconductor* devel branch becomes
> the
> > *Bioconductor* release branch."), this rather refers to the
> forward-looking
> > guideline that the cutting-edge version of any R package should be
> > compatible with the cutting edge version of R, and that developers should
> > be working with R-devel to ensure this.
> > In other words, this only refers to the version of R that the developer
> > should have installed on their own machine. It does not request users to
> > make R-devel a _requirement_ of their package.
> >
> > I hope this addresses your question better, and I am curious to hear if
> > anyone else has an opinion or precisions to weigh in on this topic.
> >
> > Best,
> > Kevin
> >
> >
> > On Mon, Feb 19, 2018 at 12:19 PM, Alexey Sergushichev <
> alserg...@gmail.com>
> > wrote:
> >
> >> Hello Kevin,
> >>
> >> Well, bioc-devel packages are tested against bioc-devel (and R-3.5) in
> any
> >> case. What I'm saying is that aside from testing the package against
> >> bioc-devel, I can as well test against bioc-release too on my own. If
> the
> >> package doesn't work with bioc-devel it shouldn't pass bioc-devel
> checks,
> >> if the package is properly developed and has a good test coverage. So I
> see
> >> no problem in allowing developers to test against other versions, on
> top of
> >> developing against bioc-devel. And as it's only possible to install the
> >> package from github and not from Bioconductor, the developer alone is
> >> responsible for the package to work properly.
> >>
> >> I can't really see a scenario, where requiring R >= 3.5 helps to improve
> >> the package quality.
> >>
> >>> A short-term workaround can be to create a git branch (e.g. "3.4").
> >>
> >> That's the way I'm doing too, but supporting two branches different only
> >> in R version looks ridiculous and unnecessary.
> >>
> >> --
> >> Alexey
> >>
> >>
> >>
> >>
> >>
> >> On Mon, Feb 19, 2018 at 12:48 PM, Kevin RUE <kevinru...@gmail.com>
> wrote:
> >>
> >>> Dear Alexey,
> >>>
> >>> The reason is somewhat implicitly given at https://www.bioconductor.or
> >>> g/developers/how-to/useDevel/ :
> >>> "Package authors should develop against the version of *R* that will be
> >>> available to users when the *Bioconductor* devel branch becomes the
> >>> *Bioconductor* release branch."
> >>>
> >>> In other words, developing against the _next_ version of R ensures that
> >>> all packages in development are tested in the environment where they
> will
> >>> be released to the general community. In particular, that environment
> >>> includes the latest devel version of all Bioconductor packages, that
> will
> >>> become their next release version.
> >>> If developers were allowed to develop and test their package in the
> >>> _current_ version of R, there is no guarantee that those packages would
> >>> still work when they are made available with the _next_ version of R
> (e.g.
> >>> if one of their dependencies is about to introduce some breaking
> changes).
> >>> That could cause all sorts of trouble in the first builds on the next
> >>> Bioconductor release, which is meant to be a place storing stable
> working
> >>> code.
> >>>
> >>> Overall, you will do yourself and your users a favor developing with
> the
> >>> _next_ version of R, as this is a forward-looking strategy, as
> explained
> >>> above. In contrast, the short-term benefit of developing with the
> _current_
> >>> version of R is largely outweighed by the risk of wasting time looking
> at
> >>> code that is about to be deprecated.
> >>>
> >>> A short-term workaround can be to create a git branch (e.g. "3.4"),
> where
> >>> the R version requirement is downgraded. Then, you can always keep
> >>> developing against R-devel on your master branch and back-port the more
> >>> recent commit to the "3.4" branch by typing "git rebase master 3.4" in
> your
> >>> shell.
> >>> A recent example of this situation can be found in the discussion here
> as
> >>> a branch to the original repository https://github.com/csoneson/iS
> >

Re: [Bioc-devel] R version check in BiocChech

[Alexey Sergushichev]

Hello Kevin,

Well, bioc-devel packages are tested against bioc-devel (and R-3.5) in any
case. What I'm saying is that aside from testing the package against
bioc-devel, I can as well test against bioc-release too on my own. If the
package doesn't work with bioc-devel it shouldn't pass bioc-devel checks,
if the package is properly developed and has a good test coverage. So I see
no problem in allowing developers to test against other versions, on top of
developing against bioc-devel. And as it's only possible to install the
package from github and not from Bioconductor, the developer alone is
responsible for the package to work properly.

I can't really see a scenario, where requiring R >= 3.5 helps to improve
the package quality.

> A short-term workaround can be to create a git branch (e.g. "3.4").

That's the way I'm doing too, but supporting two branches different only in
R version looks ridiculous and unnecessary.

--
Alexey





On Mon, Feb 19, 2018 at 12:48 PM, Kevin RUE <kevinru...@gmail.com> wrote:

> Dear Alexey,
>
> The reason is somewhat implicitly given at https://www.bioconductor.or
> g/developers/how-to/useDevel/ :
> "Package authors should develop against the version of *R* that will be
> available to users when the *Bioconductor* devel branch becomes the
> *Bioconductor* release branch."
>
> In other words, developing against the _next_ version of R ensures that
> all packages in development are tested in the environment where they will
> be released to the general community. In particular, that environment
> includes the latest devel version of all Bioconductor packages, that will
> become their next release version.
> If developers were allowed to develop and test their package in the
> _current_ version of R, there is no guarantee that those packages would
> still work when they are made available with the _next_ version of R (e.g.
> if one of their dependencies is about to introduce some breaking changes).
> That could cause all sorts of trouble in the first builds on the next
> Bioconductor release, which is meant to be a place storing stable working
> code.
>
> Overall, you will do yourself and your users a favor developing with the
> _next_ version of R, as this is a forward-looking strategy, as explained
> above. In contrast, the short-term benefit of developing with the _current_
> version of R is largely outweighed by the risk of wasting time looking at
> code that is about to be deprecated.
>
> A short-term workaround can be to create a git branch (e.g. "3.4"), where
> the R version requirement is downgraded. Then, you can always keep
> developing against R-devel on your master branch and back-port the more
> recent commit to the "3.4" branch by typing "git rebase master 3.4" in your
> shell.
> A recent example of this situation can be found in the discussion here as
> a branch to the original repository https://github.com/csoneson/iS
> EE/pull/124 and here as a fork https://github.com/mdshw5
> /iSEE/commit/6fb98192a635a6222491b66fb0474dc38f922495
>
> I hope this helps.
>
> Best wishes,
> Kevin
>
>
> On Mon, Feb 19, 2018 at 8:02 AM, Alexey Sergushichev <alserg...@gmail.com>
> wrote:
>
>> Dear Bioconducotr community,
>>
>> I wonder, what is the reason behind requirement for dependency R >= 3.5
>> (currently) for new packages?
>>
>> As a developer I really want an installation of my package to be as easy
>> as
>> possible and want my package to be easily installed from github. So
>> currently, when I develop a package I put a R >= 3.4 in my DESCRIPTION and
>> test it using Travis against bioc-release. Then, before submission
>> to Bioconductor, I have to change R >= 3.4 dependency to R >= 3.5, so that
>> the package passes BiocCheck. However, most users don't have R-devel
>> installed, so they have R 3.4 in the best case, and for these users I
>> create another repository branch with R >= 3.4 dependency.
>>
>> Overall, it is quite bothersome and it doesn't really make sense to me to
>> to restrict potential users in this way. Am I the only one who have issues
>> with this? Am I missing something? Or may be this check could be removed?
>>
>> Best,
>> Alexey Sergushichev
>>
>> [[alternative HTML version deleted]]
>>
>> ___
>> Bioc-devel@r-project.org mailing list
>> https://stat.ethz.ch/mailman/listinfo/bioc-devel
>>
>
>

[[alternative HTML version deleted]]

___
Bioc-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/bioc-devel

[Bioc-devel] R version check in BiocChech

[Alexey Sergushichev]

Dear Bioconducotr community,

I wonder, what is the reason behind requirement for dependency R >= 3.5
(currently) for new packages?

As a developer I really want an installation of my package to be as easy as
possible and want my package to be easily installed from github. So
currently, when I develop a package I put a R >= 3.4 in my DESCRIPTION and
test it using Travis against bioc-release. Then, before submission
to Bioconductor, I have to change R >= 3.4 dependency to R >= 3.5, so that
the package passes BiocCheck. However, most users don't have R-devel
installed, so they have R 3.4 in the best case, and for these users I
create another repository branch with R >= 3.4 dependency.

Overall, it is quite bothersome and it doesn't really make sense to me to
to restrict potential users in this way. Am I the only one who have issues
with this? Am I missing something? Or may be this check could be removed?

Best,
Alexey Sergushichev

[[alternative HTML version deleted]]

___
Bioc-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/bioc-devel

[Bioc-devel] Incorrect order of installing dependencies on OS X in bioc-devel in travis

[Alexey Sergushichev]

Hello all,

I'm using travis for checking my project build and found something that
looks like a bug in how biocLite installs package dependencies. It appears
that at some point biocLite started to install them in an alphabet order,
not topological, and specifically on OS X.

I've made a small dummy package to illustrate this: see
https://github.com/assaron/travis-test and corresponding travis build
https://travis-ci.org/assaron/travis-test.

There reactome.db package should be installed but fails on osx platform in
bioc-devel version. What happens there is reactome.db is installed before
RSQLite, while reactome.db dependes on RSQLite via AnnotationDbi (
https://travis-ci.org/assaron/travis-test/jobs/214404313#L630). Compare it
with bioc-release version:
https://travis-ci.org/assaron/travis-test/jobs/214404316#L543 or bioc-devel
but on linux: https://travis-ci.org/assaron/travis-test/jobs/214389446#L928

Can anyone reproduce this behavior at their OS X machine? Is this bug in
biocLite or Travis?

Best,
Alexey

[[alternative HTML version deleted]]

___
Bioc-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/bioc-devel

[Bioc-devel] Bioc-devel, Travis & OS X build failure

[Alexey Sergushichev]

Hi,

Recently something happened that broke Travis builds for Bioconductor devel
version on OS X. I found several packages affected by it:
https://travis-ci.org/GuangchuangYu/GOSemSim/jobs/174744022
https://travis-ci.org/ctlab/fgsea/jobs/177261385
https://travis-ci.org/Przemol/seqplots/jobs/172987310

The problem seems to appear from bad order of packages installation. So in
the first two examples RSQLite package is being installed later then
packages depending on it (org.Hs.eg.db and reactome.db).

Does anyone have an idea why this could happen? Have something OSX-specific
changed with new Bioc-devel version?

Best,
Alexey

[[alternative HTML version deleted]]

___
Bioc-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/bioc-devel

Re: [Bioc-devel] Citation info still not displayed correctly for some packages

[Alexey Sergushichev]

I see.

> As a developer I would choose to write my CITATION file in a way that did
not require the package to be installed.
I agree. I would suggest then to include this into BiocCheck, so that a
warning or at least a note could be generated, when citation is not working
properly.

--
Alexey

On Tue, Aug 30, 2016 at 3:08 PM, Martin Morgan <
martin.mor...@roswellpark.org> wrote:

> On 08/30/2016 06:56 AM, Alexey Sergushichev wrote:
>
>> Martin,
>>
>> Won't it be easier to include actually installation for each package in
>> the build script, but into a separate temp folder? Thus every package
>> will be isntalled and citation() should work fine.
>>
>
> installation is computationally costly and the the build system is taxed
> for resources. We do have new hardware in the works and if that loosens the
> bottleneck then yes, we would  install all packages.
>
> It is convenient to be able to get citation information from packages that
> are not installed, and the 'meta' argument to readCitationFile() seems to
> have been introduced for exactly this reason. As a developer I would choose
> to write my CITATION file in a way that did not require the package to be
> installed.
>
> Martin
>
>
>> Best,
>> Alexey
>>
>> On Tue, Aug 30, 2016 at 1:17 AM, Martin Morgan
>> <martin.mor...@roswellpark.org <mailto:martin.mor...@roswellpark.org>>
>> wrote:
>>
>> On 08/29/2016 05:40 PM, Ramon Diaz-Uriarte wrote:
>>
>>
>> Dear All,
>>
>> At least for some packages
>> (http://bioconductor.org/packages/devel/bioc/html/OncoSimulR.html
>> <http://bioconductor.org/packages/devel/bioc/html/OncoSimulR.html>)
>> the
>> citation info is still not displayed correctly. I double checked
>> installing
>> from BioC just now, and the citation is not the one shown in the
>> landing
>> page on BioC;  the vignette
>> (http://www.bioconductor.org/packages/3.4/bioc/vignettes/Onc
>> oSimulR/inst/doc/OncoSimulR.html#15_citing_oncosimulr_and_
>> other_documentation
>> <http://www.bioconductor.org/packages/3.4/bioc/vignettes/Onc
>> oSimulR/inst/doc/OncoSimulR.html#15_citing_oncosimulr_and_
>> other_documentation>)
>>
>> also shows the output from citation("OncoSimulR"), which again
>> is not the
>> same as in the BioC page.
>>
>> I think that at least in this case the citation info has not
>> been updated
>> in the last two builds.
>>
>>
>> biocViews (which processes the citations) was updated in the last
>> build, it should be used in the next build. I'll keep an eye on it.
>>
>> OncoSimulR seems to have a valid CITATION file.
>>
>> For a little more information, there are a number of outstanding
>> problems with citation processing. Citation information is added
>> using readCitationFile() applied to the package _source_, rather
>> than the installed package. This is because some packages (those
>> without any reverse dependencies) are never actually installed on
>> the build system -- they are built into a tar ball and checked, and
>> the built tarball is used to generate citation information.
>>
>> This means that CITATION files that do things like
>> packageDescription("foo") fail, because "foo" is not installed. The
>> current solution is to rely on the 'meta' argument to
>> readCitationFile(), so CITATION files can replace lines like
>>
>> version <- packageDescription("foo")$Version
>>
>> with
>>
>> version <- meta$Version
>>
>> or more flexibly
>>
>> if (!exists("meta") || is.null(meta))
>> meta <- packageDescription("nlme")
>>
>> and one can test that one has a valid CITATION file with
>>
>> descr = packageDescription("pkg-name", "/path/to/pkg")
>> readCitationFile("/path/to/pkg/pkg-name/inst/CITATION", descr)
>>
>> There are related problems, e.g., with use of the knitrcitation or
>> omitting the required field 'textVersion', and a bug (generating a
>> warning, but apparently not compromising the citation) when a url or
>> doi field contains an encoded url, as
>>
>> > xx <<- "\\url{http://foo%3Fbar};; con <- textConnection(xx);
>> parse_Rd(con, fragmen

Re: [Bioc-devel] Citation info still not displayed correctly for some packages

[Alexey Sergushichev]

Martin,

Won't it be easier to include actually installation for each package in the
build script, but into a separate temp folder? Thus every package will be
isntalled and citation() should work fine.

Best,
Alexey

On Tue, Aug 30, 2016 at 1:17 AM, Martin Morgan <
martin.mor...@roswellpark.org> wrote:

> On 08/29/2016 05:40 PM, Ramon Diaz-Uriarte wrote:
>
>>
>> Dear All,
>>
>> At least for some packages
>> (http://bioconductor.org/packages/devel/bioc/html/OncoSimulR.html) the
>> citation info is still not displayed correctly. I double checked
>> installing
>> from BioC just now, and the citation is not the one shown in the landing
>> page on BioC;  the vignette
>> (http://www.bioconductor.org/packages/3.4/bioc/vignettes/Onc
>> oSimulR/inst/doc/OncoSimulR.html#15_citing_oncosimulr_and_
>> other_documentation)
>> also shows the output from citation("OncoSimulR"), which again is not the
>> same as in the BioC page.
>>
>> I think that at least in this case the citation info has not been updated
>> in the last two builds.
>>
>
> biocViews (which processes the citations) was updated in the last build,
> it should be used in the next build. I'll keep an eye on it.
>
> OncoSimulR seems to have a valid CITATION file.
>
> For a little more information, there are a number of outstanding problems
> with citation processing. Citation information is added using
> readCitationFile() applied to the package _source_, rather than the
> installed package. This is because some packages (those without any reverse
> dependencies) are never actually installed on the build system -- they are
> built into a tar ball and checked, and the built tarball is used to
> generate citation information.
>
> This means that CITATION files that do things like
> packageDescription("foo") fail, because "foo" is not installed. The current
> solution is to rely on the 'meta' argument to readCitationFile(), so
> CITATION files can replace lines like
>
> version <- packageDescription("foo")$Version
>
> with
>
> version <- meta$Version
>
> or more flexibly
>
> if (!exists("meta") || is.null(meta))
> meta <- packageDescription("nlme")
>
> and one can test that one has a valid CITATION file with
>
> descr = packageDescription("pkg-name", "/path/to/pkg")
> readCitationFile("/path/to/pkg/pkg-name/inst/CITATION", descr)
>
> There are related problems, e.g., with use of the knitrcitation or
> omitting the required field 'textVersion', and a bug (generating a warning,
> but apparently not compromising the citation) when a url or doi field
> contains an encoded url, as
>
> > xx <<- "\\url{http://foo%3Fbar};; con <- textConnection(xx);
> parse_Rd(con, fragment=TRUE, permissive=TRUE)
> Warning in withCallingHandlers(.External2(C_parseRd, tcon, srcfile,
> "UTF-8",  :
>   :2: unexpected END_OF_INPUT '
> '
> \url{http://foo%3Fbar}
> }
>
> Here is a summary of the issues I know about; the 'err' and 'warn' labels
> refer to how R reports the initial error; the packageDescription 'warnings'
> actually mean that the CITATION file may not be parsed by the build system.
>
> ## > names(err)
> ## [1] "bioassayR"# knitcitations()
> ## [2] "ChemmineR"# knitcitations()
> ## [3] "clippda"  # missing textVersion
> ## [4] "eiR"  # knitcitations()
> ## [5] "fmcsR"# knitcitations()
> ## [6] "metagenomeSeq"# packageVersion()
> ## [7] "SomatiCA" # missing textVersion
> ## > names(warn)
> ##  [1] "ALDEx2"  # url encoding '10.1371%2'
> ##  [2] "aroma.light" # print(citn, style="html"); trailing } in title
> ##  [3] "birte"   # packageDescription()
> ##  [4] "BRAIN"   # packageDescription()
> ##  [5] "ChAMP"   # doi encoding %2F
> ##  [6] "ChIPpeakAnno"# url encoding %2F
> ##  [7] "CoGAPS"  # packageDescription()
> ##  [8] "derfinderHelper"  # packageDescription()
> ##  [9] "derfinderPlot"
> ## [10] "destiny" # packageDescription()
> ## [11] "fabia"   # packageDescription()
> ## [12] "flowFP"  # packageDescription()
> ## [13] "GenomicAlignments"# url encoding
> ## [14] "GenomicFeatures"  # url encoding
> ## [15] "GenomicRanges"# url encoding
> ## [16] "Genominator" # packageDescription()
> ## [17] "GOSim"   # packageDescription()
> ## [18] "GSRI"# packageDescription()
> ## [19] "hapFabia"# packageDescription()
> ## [20] "kebabs"  # packageDescription()
> ## [21] "manta"   # packageDescription()
> ## [22] "mdgsa"   # url encoding
> ## [23] "MEDME"   # packageDescription()
> ## [24] "miRLAB"  # url encoding
> ## [25] "networkBMA"  # packageDescription()
> ## [26] "pcaGoPromoter" # url encoding
> ## [27] "podkat"  # packageDescription()
> ## [28] "procoil" # packageDescription()
> ## [29] "Rbowtie" # packageDescription()
> ## [30] "Rcade"   # packageDescription()
> ## [31] "Rchemcpp"# packageDescription()
> ## [32] "rfPred"  # packageDescription()
> ## [33] "sigaR"   # packageDescription()
> ## [34] "SIM" # 

Re: [Rd] Using unit-tests as examples

[Alexey Sergushichev]

Yes, this may work, but this way I have to have one test per file,
which is not very convenient.

---
Alexey


On Sat, Jan 18, 2014 at 7:43 PM, Hadley Wickham h.wick...@gmail.com wrote:
 If you're using roxygen2, you can use @example tag to include an
 external file into the examples.

 Hadley

 On Sat, Jan 18, 2014 at 7:18 AM, Alexey Sergushichev
 alserg...@gmail.com wrote:
 Hi,

 Which is the best way to use unit tests as examples for documentation?
 I use testthat, but if there is a good way to do this, for example,
 only with RUnit, it'd still be good to know.

 Unit-tests are usually simple and concise, so they are good candidates
 for example code, but I don't want to copy them into documentation and
 maintain by hands. I tried to google how people handle this, but
 didn't find anything.

 ---
 Best regards,
 Alexey

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



 --
 http://had.co.nz/

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

[Rd] Using unit-tests as examples

[Alexey Sergushichev]

Hi,

Which is the best way to use unit tests as examples for documentation?
I use testthat, but if there is a good way to do this, for example,
only with RUnit, it'd still be good to know.

Unit-tests are usually simple and concise, so they are good candidates
for example code, but I don't want to copy them into documentation and
maintain by hands. I tried to google how people handle this, but
didn't find anything.

---
Best regards,
Alexey

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