On Mon, Feb 19, 2018 at 11:27 AM, Alexey Sergushichev <alsergbox at gmail.com
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
of R. In a way, that is even good practice, considering that many HPC
do not always have access to the latest version of R, and that Travis
making this fairly easy.
Now, with regard to your latest reply, I am wondering whether we're
confusion here between the "R?x.x" requirement, and the version(s) of
that you use to develop/test your package (the version of R installed
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
that the package has been tested/validated for. This does not
have to be the _next_ version of R (see the core Bioc package
am sure there are older requirements in other packages).
Here, I think the decision here boils down to how far back in terms
versions the developer is willing to support the package. I suppose
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
will be available to users when the *Bioconductor* devel branch
*Bioconductor* release branch."), this rather refers to the
guideline that the cutting-edge version of any R package should be
compatible with the cutting edge version of R, and that developers
be working with R-devel to ensure this.
In other words, this only refers to the version of R that the
should have installed on their own machine. It does not request users
make R-devel a _requirement_ of their package.
I hope this addresses your question better, and I am curious to hear
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 <
Hello Kevin,
Well, bioc-devel packages are tested against bioc-devel (and R-3.5)
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
package doesn't work with bioc-devel it shouldn't pass bioc-devel
if the package is properly developed and has a good test coverage.
no problem in allowing developers to test against other versions, on
developing against bioc-devel. And as it's only possible to install
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
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
in R version looks ridiculous and unnecessary.
--
Alexey
On Mon, Feb 19, 2018 at 12:48 PM, Kevin RUE <kevinrue67 at gmail.com>
Dear Alexey,
The reason is somewhat implicitly given at
g/developers/how-to/useDevel/ :
"Package authors should develop against the version of *R* that
available to users when the *Bioconductor* devel branch becomes the
*Bioconductor* release branch."
In other words, developing against the _next_ version of R ensures
all packages in development are tested in the environment where they
be released to the general community. In particular, that
includes the latest devel version of all Bioconductor packages, that
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
still work when they are made available with the _next_ version of R
if one of their dependencies is about to introduce some breaking
That could cause all sorts of trouble in the first builds on the
Bioconductor release, which is meant to be a place storing stable
code.
Overall, you will do yourself and your users a favor developing with
_next_ version of R, as this is a forward-looking strategy, as
above. In contrast, the short-term benefit of developing with the
version of R is largely outweighed by the risk of wasting time
code that is about to be deprecated.
A short-term workaround can be to create a git branch (e.g. "3.4"),
the R version requirement is downgraded. Then, you can always keep
developing against R-devel on your master branch and back-port the
recent commit to the "3.4" branch by typing "git rebase master 3.4"
shell.
A recent example of this situation can be found in the discussion
Dear Bioconducotr community,
I wonder, what is the reason behind requirement for dependency R >=
(currently) for new packages?
As a developer I really want an installation of my package to be as
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
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,
that
the package passes BiocCheck. However, most users don't have
installed, so they have R 3.4 in the best case, and for these
create another repository branch with R >= 3.4 dependency.
Overall, it is quite bothersome and it doesn't really make sense 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
Best,
Alexey Sergushichev
[[alternative HTML version deleted]]