[Bioc-devel] R version check in BiocChech

Vincent Carey stvjc at channing.harvard.edu
Mon Feb 19 19:03:30 CET 2018 

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/
> be9cd6e36d95f8bf873b52427d2a97fce6fbb9b9/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