[Bioc-devel] R version check in BiocChech

Mon Feb 19 17:27:37 CET 2018

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?

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