[Bioc-devel] Wish: BioC devel on R stable for more frequent package updates
rgentlem at fhcrc.org
Thu Jan 10 20:12:51 CET 2008
Hi Henrik and others,
Henrik Bengtsson wrote:
> On 07/01/2008, Wolfgang Huber <huber at ebi.ac.uk> wrote:
>> Dear all,
>> I like the suggestion a lot but...:
>> I guess the main problem is that the daily checks in Seattle are run on
>> R-devel and there is no easy way to make sure that a package also runs
>> on a different version of R. Basically Henrik's proposal shifts the
>> burden of testing that packages pass R CMD check and R CMD INSTALL on
>> all the possible versions of R that their "Depends" field allows (and
>> all platforms) to the individual maintainer. And I am not sure whether
>> everybody is ready for that, or whether it is an efficient use of our time.
> I would like to clarify that the package should still pass the daily
> builds/checks on the BioC servers which still run R devel. This is
> the only reasonable alternative. So far nothing changed. Same
> requirement as before.
In that case, I am a bit confused about what your request really is.
If the devel version of your package works with R-devel, then that is
fine and in accord. If it also happens to work with R-release that is
great too. Anyone that wanted to use it could install it and see
whether or not it worked. I don't think it would be a good idea to have
a separate test paradigm for devel packages against release R (and that
is the only way I can see for a user to know which packages do work in
The reason we have separated out release and devel, is in part to
reduce the amount of legacy code we need to support (resources are very
limited). But it is also designed to allow us to take advantages of
changes in R (we changed CHARSXP handling not that long ago) without
interfering in any way with the users of release. Before we did that
the user experience was a lot less uniform, so we are loath to change
back to a situation where users were having more problems.
I would sooner see you put some new functionality in BioC-release and
maintain the synchronization of R-release - BioC-release or R-devel and
> Yes, if the package also pass checks on R release and that is set in
> "Depends", then the BioC servers cannot test that as well. It will be
> something the maintainer has to verify. However, since it pass the
> checks on R devel the package still meets the requirement for BioC
> devel (on R devel). The downside is that there is a risk for a
> package to be broken on R stable but not R devel, which happens in
> case the developer makes a commit without checking it on R stable.
> (Indeed, we have the devel version of affxparser depending on R stable
> as we speak)
I am not sure what that means, but if it means that affxparser does
not build against R-devel, then that is unfortunate.
> The burden of checking a package is only on those developers who have
> R stable in "Depends" in their BioC devel packages. Anyone who don't
> want to do that and stick with the current approach, just have to make
> sure R devel is in "Depends". ...or did I miss something?
I don't think you can do that. You either need to say
R=xxx or R >= xxx, and if you use the first, then for a devel
package it had better be R-devel that is being specified, or it will
fail our builds since we build with R-devel. In the second case, then
we test against R-devel (even if R-release is specified) on the devel
arm. Users are free to try and see what does or does not install, but
there are no tools that I can see how we can easily operationalize to
let them discriminate between a developer who has the intention you
have, and one who merely forgot to update.
You will also get in no end of trouble with automatic tools like
update.packages as there is no easy way to distinguish what repository
to use, on a per package basis. So users that want those tools are
going to either get all release, all devel, or have to write extra code
for intermediate work.
And finally, R devel and BioC devel are not that unstable, that one
cannot find a version that works and can be used with relatively little
Please correct me if I have gotten the wrong impression somewhere
along the way.
>> Best wishes
>> Wolfgang Huber EBI/EMBL Cambridge UK http://www.ebi.ac.uk/huber
>> Henrik Bengtsson wrote:
>>> I'm quite sure something similar to the below has been discussed
>>> before. I've got aroma.affymetrix
>>> (http://www.braju.com/R/aroma.affymetrix/) and I am thinking of making
>>> it available on Bioconductor trying to meet the following:
>>> 1) The package is designed to work with the release version of R
>>> (v2.6.x) in order to be more user friendly (and more stable).
>>> 2) The package is frequently updated (a few times a month).
>>> 3) Users should be able to run it on R release (or R devel, if they
>>> are in that league).
>>> 4) Users should be able to use other BioC release package (or BioC
>>> devel packages,
>>> if they are in that league).
>>> I'm currently providing the above via my own repository using standard
>>> R installation mechanisms. However, the BioC release/devel repository
>>> system does not support the above, because:
>>> A) BioC release should not be updated beyond bug fixes and minor updates.
>>> B) The BioC devel branch requires R devel.
>>> What are the objectives for strictly enforcing R devel on BioC devel?
>>> Couldn't the latter requirement, which is mostly an installation
>>> script requirement, instead be taken care of by the regular package
>>> dependencies? That is, you can put a package in BioC devel that
>>> depends on R stable and as long as other package dependencies install
>>> on R stable, then everything should be fine (relying on the standard R
>>> installation mechanisms). For example, if Biobase requires R devel,
>>> then all packages depending on it will also need R devel, but
>>> non-Biobase packages will not "inherit" that dependency on R devel.
>>> Nightly builds and checks can still be done on R devel, meaning a BioC
>>> devel package should install on R devel, but may also install on R
> Bioc-devel at stat.math.ethz.ch mailing list
Robert Gentleman, PhD
Program in Computational Biology
Division of Public Health Sciences
Fred Hutchinson Cancer Research Center
1100 Fairview Ave. N, M2-B876
PO Box 19024
Seattle, Washington 98109-1024
rgentlem at fhcrc.org
More information about the Bioc-devel