[Bioc-devel] R version check in BiocChech
Aaron Lun
alun at wehi.edu.au
Mon Feb 19 18:44:55 CET 2018
> > 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")'.
There seem to be two issues here.
The first is regarding the usability of your specific package. For this,
Kevin's suggestion (and what you are already doing) is pretty
reasonable. It's just a branch with a single altered commit (>= 3.5 to
>= 3.4); it costs nothing, and you can delete it later.
However, this "solution" will only last until the next BioC release, at
which point biocLite() will only work on R 3.5.*. So, sooner or later,
your users will have to update their versions of R.
Which leads us to the second question. Should Bioconductor, as a
project, enforce the use of the latest R version? The core team will
have better things to say than me on this topic, but for me, the answer
is an unqualified yes. We get the latest features, bugfixes and
improvements; a considerable set of benefits, IMHO.
> > 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's true that a developer might not need the latest cutting-edge
features in the latest version of R. But they should incorporate bug
fixes to the underlying infrastructure, or changes to existing
functionality that result in different behaviour.
Of course, it would be difficult to ask every developer to read through
the NEWS to see if the changes affect their package. It is much easier
for everyone to just use the latest version of R; then we only have to
deal with bugs in the latest version, not previously solved ones.
And besides; let's say, hypothetically, BioC didn't have a R version
requirement. Unless you're using a quite restricted subset of packages,
you'll encounter a package somewhere that requires the latest R version.
In my workflows, I know that I load at least 100 packages; only one of
them needs to have R (>= 3.5) to force me to upgrade anyway.
> > 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.
Yes, that's the point. To paraphrase what I tell my colleagues:
Bugs in a BioC-release package with R 3.4 = my problem
Bugs in a BioC-devel package with R 3.5 = my problem
Bugs in a BioC-devel package with R 3.4 = not my problem
From my perspective, the version requirements in biocLite() ensure that
the user is doing things properly; and if they follow the rules, any
bugs are therefore the fault of my package. If the users don't follow
the rules, they're on their own - but at least they know what the rules
are, because it's pretty inconvenient to break them.
Cheers,
Aaron
> On Mon, Feb 19, 2018 at 6:38 PM, Aaron Lun <alun at wehi.edu.au
> <mailto: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
> <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 <mailto: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 <mailto: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 <mailto: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 <mailto:Bioc-devel at r-project.org>
> mailing list
> >>>> https://stat.ethz.ch/mailman/listinfo/bioc-devel
> <https://stat.ethz.ch/mailman/listinfo/bioc-devel>
> >>>>
> >>>
> >>>
> >>
> >
> > [[alternative HTML version deleted]]
> >
> > _______________________________________________
> > Bioc-devel at r-project.org <mailto:Bioc-devel at r-project.org>
> mailing list
> > https://stat.ethz.ch/mailman/listinfo/bioc-devel
> <https://stat.ethz.ch/mailman/listinfo/bioc-devel>
> >
> _______________________________________________
> Bioc-devel at r-project.org <mailto:Bioc-devel at r-project.org> mailing list
> https://stat.ethz.ch/mailman/listinfo/bioc-devel
> <https://stat.ethz.ch/mailman/listinfo/bioc-devel>
>
>
More information about the Bioc-devel
mailing list