[Bioc-devel] R version check in BiocChech

Shepherd, Lori Lori.Shepherd at RoswellPark.org
Tue Feb 20 14:05:37 CET 2018


Depending on your reviewer, they MAY let you slide with a different version dependency despite the BiocCheck WARNING... maybe...


However ...


It is strongly, strongly recommended that all new package depend on the version of R that it will be released under.  New packages currently being accepted will be released under Bioc 3.7 which will be associated with R 3.5.   So as mentioned, eventually users will want to update to use the latest versions anyways.  While new packages could be compatible with earlier versions of Bioc and R releases,  we at Bioconductor cannot guarantee that, which is why we generally insist for consistency sake that the R requirement is the latest version.  R versions can have subtle difference that can have a cascading effect on packages - similarly with packages that are used in dependencies - Since the Bioconductor build system is set up to test under the latest version testing scenario, that is all we can guarantee for compatibility and why we check for this.


Perhaps others will want to chime in as well with further reasoning.



Lori Shepherd

Bioconductor Core Team

Roswell Park Cancer Institute

Department of Biostatistics & Bioinformatics

Elm & Carlton Streets

Buffalo, New York 14263

________________________________
From: Bioc-devel <bioc-devel-bounces at r-project.org> on behalf of Alexey Sergushichev <alsergbox at gmail.com>
Sent: Tuesday, February 20, 2018 4:26:35 AM
To: Vincent Carey
Cc: bioc-devel at r-project.org
Subject: Re: [Bioc-devel] R version check in BiocChech

> 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 <stvjc at channing.harvard.edu>
wrote:

>
>
> On Mon, Feb 19, 2018 at 11:27 AM, Alexey Sergushichev <alsergbox at 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 <alun at 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 annoyance in the first option is better than the chronic
>> > grief of the second option, especially given that the solution to the
>> > problem in the second option would be to update R anyway.
>> >
>> > 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.
>> >
>> > -Aaron
>> >
>> > On 19/02/18 14:55, Kevin RUE wrote:
>> > > Hi Alexey,
>> > >
>> > > I do agree with you that there is no harm in testing against other
>> > version
>> > > of R. In a way, that is even good practice, considering that many HPC
>> > users
>> > > do not always have access to the latest version of R, and that Travis
>> is
>> > > making this fairly easy.
>> > >
>> > > Now, with regard to your latest reply, I am wondering whether we're
>> > having
>> > > confusion here between the "R�x.x" requirement, and the version(s) of
>> R
>> > > that you use to develop/test your package (the version of R installed
>> on
>> > > your own machine).
>> > >
>> > > First, I think the "R�x.x" does not have an explicit rule.
>> > > To me, the point of this requirement is to declare the oldest version
>> of
>> > R
>> > > that the package has been tested/validated for. This does not
>> necessarily
>> > > have to be the _next_ version of R (see the core Bioc package
>> S4Vectors:
>> > > https://bioconductor.org/packages/release/bioc/html/S4Vectors.html,
>> and
>> > I
>> > > am sure there are older requirements in other packages).
>> > > 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.
>> > >
>> > > On a separate note, going back to the Bioc guideline that I initially
>> > > highlighted ("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."), 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 <
>> > alsergbox at 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 <kevinrue67 at 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 <
>> > alsergbox at 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 at r-project.org mailing list
>> > >>>> https://stat.ethz.ch/mailman/listinfo/bioc-devel
>> > >>>>
>> > >>>
>> > >>>
>> > >>
>> > >
>> > >       [[alternative HTML version deleted]]
>> > >
>> > > _______________________________________________
>> > > Bioc-devel at r-project.org mailing list
>> > > https://stat.ethz.ch/mailman/listinfo/bioc-devel
>> > >
>> > _______________________________________________
>> > Bioc-devel at r-project.org mailing list
>> > https://stat.ethz.ch/mailman/listinfo/bioc-devel
>> >
>>
>>         [[alternative HTML version deleted]]
>>
>> _______________________________________________
>> Bioc-devel at r-project.org mailing list
>> https://stat.ethz.ch/mailman/listinfo/bioc-devel
>>
>
>

        [[alternative HTML version deleted]]

_______________________________________________
Bioc-devel at 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]]



More information about the Bioc-devel mailing list