Re: [Bioc-devel] No curatedMetagenomicData build triggered
Hi Levi, We've had one experimental data build since the release, posted on Nov 1. Data experiment packages build on Tues, Thurs and Sun. Release should continue to follow this schedule. The devel builds are taking a very long time to complete and overlapping each other which means less dependable builds. Please see this post: https://stat.ethz.ch/pipermail/bioc-devel/2018-November/014281.html Valerie On 11/3/18 7:08 AM, Levi Waldron wrote: > I remember now (I think) that experimental data packages are built on > Wednesday and *Saturday* nights - in which case I’ll just check again > tomorrow morning. > > On Sat, Nov 3, 2018 at 8:59 AM Levi Waldron > wrote: > >> curatedMetagenomicData hasn't built yet on the new release or devel. I >> believe this was originally because the required ExperimentHub database >> update occurred after the last curatedMetagenomicData version bump, but >> since I bumped the version on Thursday it still hasn't built. Can you >> advise? >> 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. ___ Bioc-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/bioc-devel
Re: [Bioc-devel] choosing R version dependency for existing packages
I'm using Depends: R (>= 2.12.0) to communicate that I've tested/verified that the package works as far back as R 2.12.0. Also, since R (>= 3.5.1) and R (>= 3.5.0) has been mentioned here, in 'Writing R Extensions' there is: "It is inadvisable to use a dependence on R with patchlevel (the third digit) other than zero. Doing so with packages which others depend on will cause the other packages to become unusable under earlier versions in the series, and e.g. versions 3.x.1 are widely used throughout the Northern Hemisphere academic year." which suggests one should aim for R (>= x.y.0). This is also tested by `R CMD check --as-cran` or `_R_CHECK_R_DEPENDS_=warn R CMD check`, e.g. * checking package directory ... OK * checking DESCRIPTION meta-information ... WARNING Dependence on R version ‘3.5.1’ not with patchlevel 0 * checking top-level files ... OK The source code comments (https://github.com/wch/r-source/blob/R-3-5-branch/src/library/tools/R/check.R#L982-L1008) give more motivation behind this check: ## Dependence on say R >= 3.4.3 when 3.4 is current can ## cause problems with revdeps (and did for 3.2.x). ## We only check recent ones: maybe previous two ## (R-release and R-old-release) while this is R-devel I believe this is written from the perspective of CRAN and their tests. /Henrik On Sat, Nov 3, 2018 at 12:27 PM Paul Shannon wrote: > > Thanks, Martin. > > I have backed off MotifDB’s R requirement to 3.5.0. I will experiment with > removing the requirement entirely in the new devel branch. > > - Paul > > > On Nov 3, 2018, at 1:37 AM, Martin Morgan wrote: > > > > If users are 'playing by the books' and using BiocManager::install(), the > > version of R is coupled with the version of Bioconductor / your package, so > > specifying an R version is irrelevant. In addition, saying your package has > > a dependency R >=... implies that there will be no breaking changes in some > > future R, which requires a certain amount of foresight. And using R itself > > would seem to be a requirement for an R package. So in principle my feeling > > is that it doesn't make sense to include R or an R version as a dependency. > > > > In a more practical setting it might be that your package depends on a > > specific feature of R, or that you yourself are only confident that a > > particular version of R will provide the needs of your package. It might > > then be appropriate to specify that R version. Again in the domain of the > > ideal, new R features would be introduced in R-devel, with bug fixes only > > in the point releases. So a dependency like R >= 3.5.0 would seem > > appropriate. > > > > I'm not sure whether these comments are helpful or not... __ > > > > Martin > > > > On 11/2/18, 3:19 PM, "Bioc-devel on behalf of Paul Shannon" > > > paul.thurmond.shan...@gmail.com> wrote: > > > >A user of MotifDb requests - sensibly, I think - that I loosen the > > requirement > > > > Depends: R (>= 3.5.1) > > > >which I added before the release. This seems sensible and supported > > by, for example, R (>= 2.10) in GenomicRanges. > > > >Is this, then, the heuristic? > > > > - new packages should depend on the lastest release of R > > > > - older existing packages should depend on earlier > >versions of R, possibly sticking with the version of R in > >which they originally appeared, as long as they have not > >been subsequently modified to use new R features. > > > >- Paul > > > > > > > > > > > > > > > >___ > >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 ___ Bioc-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/bioc-devel
Re: [Bioc-devel] choosing R version dependency for existing packages
Thanks, Martin. I have backed off MotifDB’s R requirement to 3.5.0. I will experiment with removing the requirement entirely in the new devel branch. - Paul > On Nov 3, 2018, at 1:37 AM, Martin Morgan wrote: > > If users are 'playing by the books' and using BiocManager::install(), the > version of R is coupled with the version of Bioconductor / your package, so > specifying an R version is irrelevant. In addition, saying your package has a > dependency R >=... implies that there will be no breaking changes in some > future R, which requires a certain amount of foresight. And using R itself > would seem to be a requirement for an R package. So in principle my feeling > is that it doesn't make sense to include R or an R version as a dependency. > > In a more practical setting it might be that your package depends on a > specific feature of R, or that you yourself are only confident that a > particular version of R will provide the needs of your package. It might then > be appropriate to specify that R version. Again in the domain of the ideal, > new R features would be introduced in R-devel, with bug fixes only in the > point releases. So a dependency like R >= 3.5.0 would seem appropriate. > > I'm not sure whether these comments are helpful or not... __ > > Martin > > On 11/2/18, 3:19 PM, "Bioc-devel on behalf of Paul Shannon" > paul.thurmond.shan...@gmail.com> wrote: > >A user of MotifDb requests - sensibly, I think - that I loosen the > requirement > > Depends: R (>= 3.5.1) > >which I added before the release. This seems sensible and supported by, > for example, R (>= 2.10) in GenomicRanges. > >Is this, then, the heuristic? > > - new packages should depend on the lastest release of R > > - older existing packages should depend on earlier >versions of R, possibly sticking with the version of R in >which they originally appeared, as long as they have not >been subsequently modified to use new R features. > >- Paul > > > > > > > >___ >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
Re: [Bioc-devel] No curatedMetagenomicData build triggered
I remember now (I think) that experimental data packages are built on Wednesday and *Saturday* nights - in which case I’ll just check again tomorrow morning. On Sat, Nov 3, 2018 at 8:59 AM Levi Waldron wrote: > curatedMetagenomicData hasn't built yet on the new release or devel. I > believe this was originally because the required ExperimentHub database > update occurred after the last curatedMetagenomicData version bump, but > since I bumped the version on Thursday it still hasn't built. Can you > advise? > -- Levi Waldron http://www.waldronlab.io Associate Professor of BiostatisticsCUNY School of Public Health US: +1 646-364-9616 Skype: levi.waldron [[alternative HTML version deleted]] ___ Bioc-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/bioc-devel
[Bioc-devel] No curatedMetagenomicData build triggered
curatedMetagenomicData hasn't built yet on the new release or devel. I believe this was originally because the required ExperimentHub database update occurred after the last curatedMetagenomicData version bump, but since I bumped the version on Thursday it still hasn't built. Can you advise? [[alternative HTML version deleted]] ___ Bioc-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/bioc-devel
Re: [Bioc-devel] choosing R version dependency for existing packages
If users are 'playing by the books' and using BiocManager::install(), the version of R is coupled with the version of Bioconductor / your package, so specifying an R version is irrelevant. In addition, saying your package has a dependency R >=... implies that there will be no breaking changes in some future R, which requires a certain amount of foresight. And using R itself would seem to be a requirement for an R package. So in principle my feeling is that it doesn't make sense to include R or an R version as a dependency. In a more practical setting it might be that your package depends on a specific feature of R, or that you yourself are only confident that a particular version of R will provide the needs of your package. It might then be appropriate to specify that R version. Again in the domain of the ideal, new R features would be introduced in R-devel, with bug fixes only in the point releases. So a dependency like R >= 3.5.0 would seem appropriate. I'm not sure whether these comments are helpful or not... __ Martin On 11/2/18, 3:19 PM, "Bioc-devel on behalf of Paul Shannon" wrote: A user of MotifDb requests - sensibly, I think - that I loosen the requirement Depends: R (>= 3.5.1) which I added before the release. This seems sensible and supported by, for example, R (>= 2.10) in GenomicRanges. Is this, then, the heuristic? - new packages should depend on the lastest release of R - older existing packages should depend on earlier versions of R, possibly sticking with the version of R in which they originally appeared, as long as they have not been subsequently modified to use new R features. - Paul ___ 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
