Hi all,

Just saw this tangentially related link to "packrat" which seems something
analogous to a virtualenv (of sorts) for R by the Rstudio folks, which I
thought might be useful

It actually doesn't solve anybody's problem here, but as I said ...
tangential :-)

http://rstudio.github.io/packrat/


On Thursday, April 24, 2014, Wolfgang Huber <whuber@embl.de> wrote:

> Hi Kasper
>
> you are right, I had misunderstood the problem.
> In that case I agree with Martin that the problem resolves into components
> that are either intractable, already addressed by deprecation policies, or
> not very important.
> Sorry for the noise.
>
>         Wolfgang
>
> On 24 Apr 2014, at 15:18, Kasper Daniel Hansen <
> kasperdanielhansen@gmail.com> wrote:
>
> > Wolfgang,
> >
> > Alejandro did not have a problem with the current release, but with the
> most recent prior release.  His issue is precisely because it is no longer
> the current (stable) release.
> >
> > Kasper
> >
> >
> > On Thu, Apr 24, 2014 at 3:05 PM, Wolfgang Huber <whuber@embl.de> wrote:
> > Hi Martin
> > to come back to the original trigger for this thread: it was not
> concerns for reproducibility, but the fact that a Bioc package in the
> current release stopped working because a CRAN package has changed in the
> meanwhile.
> > What's the most practical solution to this specific problem?
> >         Best wishes
> >         Wolfgang
> >
> >
> >
> >
> > On 23 Apr 2014, at 19:41, Martin Morgan <mtmorgan@fhcrc.org> wrote:
> >
> > > On 04/22/2014 09:47 AM, Kasper Daniel Hansen wrote:
> > >> I think we should have a CRAN snapshot (or a subset of CRAN used in
> Bioc)
> > >> inside each Bioc release; I don't know how hard that is to manage
> from a
> > >> technical point of view.
> > >
> > > I followed this thread with some interest.
> > >
> > > It would be surprisingly challenging to update even a 2.13 package --
> the build machines have moved on to other tasks, unconstrained by the
> unique system dependencies needed for 2.13 builds.
> > >
> > > The idea of a 'forever' repository snapshot seems possible, but would
> the snapshot be at the beginning of the release and hence miss the few but
> important bug fixes introduced during the release, or at the end of the
> release, which might be after the time required for the purposes of
> replication? Either way it is certain that the peanut butter would land
> face down for one's particular need. Also, the need for the user to satisfy
> system dependencies becomes increasingly challenging, even with a binary
> repository. I don't think a central 'Bioc' solution would really address
> the problem of reproducibility.
> > >
> > > It is not that 'hard' for an individual group to create a snapshot of
> Bioc and CRAN, using rsync
> > >
> > >  http://www.bioconductor.org/about/mirrors/mirror-how-to/
> > >  http://cran.r-project.org/mirror-howto.html
> > >
> > > and to use install.packages() or even biocLite to access these (see
> ?setRepositories). This would again require that the system dependencies
> for these packages are satisfied in some kind of frozen fashion.
> > >
> > > A more robust possibility is of course a virtual machine, such as the
> AMI (or a customized version) we provide
> > >
> > >  http://www.bioconductor.org/help/bioconductor-cloud-ami/#ami_ids
> > >
> > > although these have only a subset of packages installed by default.
> > >
> > > The CRAN thread referenced earlier included this post
> > >
> > >  https://stat.ethz.ch/pipermail/r-devel/2014-March/068605.html
> > >
> > > which I think makes an important distinction between exact replication
> and scientific reproducibility; it is the latter that must be the most
> interesting, and the former that we somehow seem to stumble over. The
> thread also mentions best practices -- version control
> > >
> > >  http://bioconductor.org/developers/how-to/source-control/
> > >
> > > disciplined approach to deprecation
> > >
> > >  http://bioconductor.org/developers/how-to/deprecation/
> > >
> > > package versioning
> > >
> > >  http://bioconductor.org/developers/how-to/version-numbering/
> > >
> > > and the Bioc-style approach to release that we as developers can act
> on to enhance reproducibility. What other best pract



-- 
Steve Lianoglou
Computational Biologist
Genentech

	[[alternative HTML version deleted]]

