Just to chime in, we have adopted the same snapshot policy within
Genentech; we might actually write something up on our policies, since
we've invested a lot of thought into them.
We're also set to release our repository management system (GRAN) on github
for public consumption. It was written by
Sounds great.
Kasper
On Wed, Apr 30, 2014 at 9:02 PM, Martin Morgan wrote:
> On 04/30/2014 05:30 PM, Kasper Daniel Hansen wrote:
>
>> Let me add my opinion: we do not have perfect (easy) reproducibility with
>> Bioc because we can only (easily) download the tar ball corresponding to
>> the lat
On 04/30/2014 05:30 PM, Kasper Daniel Hansen wrote:
Let me add my opinion: we do not have perfect (easy) reproducibility with
Bioc because we can only (easily) download the tar ball corresponding to
the latest commit in a given branch. I am ok with that. What I (and
Alejandro) is concerned abou
Let me add my opinion: we do not have perfect (easy) reproducibility with
Bioc because we can only (easily) download the tar ball corresponding to
the latest commit in a given branch. I am ok with that. What I (and
Alejandro) is concerned about is the inability to install even that.
There is a c
Hi,
See the latest software builds for BioC 2.13:
http://bioconductor.org/checkResults/2.13/bioc-20140405/
The number of packages that needed to be installed on the build
system in order to build and check the 750 BioC software packages
is displayed in the right-most column of the top table:
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/
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, Ka
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 wrote:
> Hi Martin
> to come back to the original t
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?
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 ch
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.
Best,
Kasper
On Tue, Apr 22, 2014 at 6:06 PM, Julian Gehring wrote:
> Hi,
>
> For most problems discussed here, it seems th
Hi,
For most problems discussed here, it seems that having a fixed version
of package is sufficient rather than a specific version. If the idea of
a snapshot with each bioc release would work (which still means one
version per package), so would requiring that version within the package
(one
Hi Julian
what if two Bioc packages require different version of the ‘same’ CRAN package?
AfaIu, the infrastructure is not designed to deal with multiple versions of a
package.
Nor would I as a user expect to have less-than-the-most recent versions of CRAN
packages in my library just because so
Hi,
For a "more general solution" one could think of specifying the version
of critical packages in the 'description' file and having a 'biocLite'
function that installs the specific version from CRAN. See e.g. the
'devtools::install_version' function for installing older packages from
the C
Hi Andrej,
Yes, that would help, that would be also a solution for my case,
installing an old version of the cran package (stamod in my case)
However, I don't know if this could be a "general solution for all
users" since when installing a package via
biocLite, the latest version of the cran
Dear Kasper,
regarding your issue with R-2.15: I was wondering whether using an
older version of Rcpp from
http://cran.r-project.org/src/contrib/Archive/Rcpp/ would help?
Cheers,
Andrzej
On Tue, Apr 22, 2014 at 2:46 PM, Kasper Daniel Hansen
wrote:
> This is because commits to this branch of Bio
This is because commits to this branch of Bioconductor has been disabled
and it is intentional.
But it raises the larger question, recently touched upon in a lengthy
thread on R-devel, on whether this is a good state of affairs for
Bioconductor. Specifically the issue has to do with dependency of
17 matches
Mail list logo
