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

Hi Robert,
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

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

Thread (6 messages)