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

[Henrik Bengtsson]

Hi Robert,

On 10/01/2008, Robert Gentleman <rgentlem at fhcrc.org> wrote:
> 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.

Yes, this basically comes down to the problem of installing a
BioC-devel package on R release.  I've wrote my own hack allowing to
"fool" biocLite() et al. about the real R version, e.g. biocLite(pkg,
rver="2.7.0") can be used on R v2.6.1 but biocLite() thinks it runs R
v2.7.0.  This is of course a hack.  It is probably better to have a
biocLite(pkg, repos="auto") where 'repos' defaults to BioC release and
devel depending on R version, but can be also be specified explicitly
as biocLite(pkgm repos="devel") to force installation of a BioC-devel
package.

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

I agree.  I like the existing test paradigm.  The only alternative is
then to trust the developer that a package really install/pass checks
on R release if they claim so - the same problems goes with CRAN
packages where you easily can claim compatibility with R v1.0.0 but
the package is only tested against the latest version.

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

That update in R (and BioC) would have caused problem for installing
BioC devel on R release, but not for all packages.  Packages written
in plain R would probably show difference.

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

No, I meant that it installs/builds on R devel, but also R release.  I
just realized that 'affxparser' was a poor example because there is
currently an error due to a totally unrelated problem.

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

But there are package that build and pass checks on both R release and
R devel - correct me if the BioC check system works differently.  The
package should be tested on R devel, but may install on R stable (and
there we have to trust the developer since no nightly tests are done
for that version).

What I am suggesting that it should be possible to provide a BioC v2.2
(devel) package as:

Package: FooBar
Version: 1.2.3
Date: 2008-01-10
Title: A Package
Depends: R (>= 2.6.0), Biobase (>= 1.16.2)

and provide an easy way to install it on R v2.6.0 (release) as well.

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

I am not familiar with how update.packages() works and how it
identifies the repository to query.  Are you saying that if you mix
BioC devel and release packages, it is not well defined what
repository update.packages() will use?

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

It all comes down to the fact that people shouldn't have to install R
devel and BioC devel just because there is a single package that is
frequently updated (and still compatible with R devel).  I believe my
suggestion can be solved by updating biocLite() et al.

Hope this clarified my proposition.

Best,

Henrik

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