[Bioc-devel] R version check in BiocChech

Alexey Sergushichev alsergbox at gmail.com
Tue Feb 20 10:26:35 CET 2018 

> 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]]

More information about the Bioc-devel mailing list