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
[Bioc-devel] R version check in BiocChech
10 messages · Kevin RUE, Aaron Lun, Vincent Carey +2 more
Dear Alexey, The reason is somewhat implicitly given at https://www.bioconductor.org/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/iSEE/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
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
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
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
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
> 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
> 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
>>> 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
>>>>
>>>
>>>
>>
>
>? ? ? ?[[alternative HTML version deleted]]
>
> _______________________________________________
> Bioc-devel at r-project.org <mailto:Bioc-devel at r-project.org>
mailing list
>
_______________________________________________
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>
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:
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
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
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:
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
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
Depending on your reviewer, they MAY let you slide with a different version dependency despite the BiocCheck WARNING... maybe... However ... It is strongly, strongly recommended that all new package depend on the version of R that it will be released under. New packages currently being accepted will be released under Bioc 3.7 which will be associated with R 3.5. So as mentioned, eventually users will want to update to use the latest versions anyways. While new packages could be compatible with earlier versions of Bioc and R releases, we at Bioconductor cannot guarantee that, which is why we generally insist for consistency sake that the R requirement is the latest version. R versions can have subtle difference that can have a cascading effect on packages - similarly with packages that are used in dependencies - Since the Bioconductor build system is set up to test under the latest version testing scenario, that is all we can guarantee for compatibility and why we check for this. Perhaps others will want to chime in as well with further reasoning. Lori Shepherd Bioconductor Core Team Roswell Park Cancer Institute Department of Biostatistics & Bioinformatics Elm & Carlton Streets Buffalo, New York 14263
From: Bioc-devel <bioc-devel-bounces at r-project.org> on behalf of Alexey Sergushichev <alsergbox at gmail.com>
Sent: Tuesday, February 20, 2018 4:26:35 AM
To: Vincent Carey
Cc: bioc-devel at r-project.org
Subject: Re: [Bioc-devel] R version check in BiocChech
Sent: Tuesday, February 20, 2018 4:26:35 AM
To: Vincent Carey
Cc: bioc-devel at r-project.org
Subject: Re: [Bioc-devel] R version check in BiocChech
> 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]] _______________________________________________ Bioc-devel at r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/bioc-devel This email message may contain legally privileged and/or confidential information. If you are not the intended recipient(s), or the employee or agent responsible for the delivery of this message to the intended recipient(s), you are hereby notified that any disclosure, copying, distribution, or use of this email message is prohibited. If you have received this message in error, please notify the sender immediately by e-mail and delete this email message from your computer. Thank you.