[Bioc-devel] Wish: BioC devel on R stable for more frequent package updates

Thu Jan 10 20:12:51 CET 2008

Hi Henrik and others,

Henrik Bengtsson wrote:
> Hi.
> 
> 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 
R-release).

  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 
BioC-devel.

> 
> 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 
effort.

   Please correct me if I have gotten the wrong impression somewhere 
along the way.

  best wishes
    Robert

> 
> Best,
> 
> Henrik
> 
>>
>> Best wishes
>>    Wolfgang
>>
>> ------------------------------------------------------------------
>> Wolfgang Huber  EBI/EMBL  Cambridge UK  http://www.ebi.ac.uk/huber
>>
>> Henrik Bengtsson wrote:
>>> Hi,
>>>
>>> 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
>>> stable.
>>>
>>> Best,
>>>
>> --
>>
> 
> _______________________________________________
> Bioc-devel at stat.math.ethz.ch mailing list
> https://stat.ethz.ch/mailman/listinfo/bioc-devel
> 

-- 
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
206-667-7700
rgentlem at fhcrc.org