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 <
kasperdanielhan...@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 <whu...@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 <mtmor...@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
