Dear list, I'm curious what people would think of a more modest proposal at this time:
State the version of the dependencies used by the package authors when the package was built. Eventually CRAN could enforce such a statement be present in the description. We encourage users to declare the version of the packages they use in publications, so why not have the same expectation of developers? This would help address the problem of archived packages that Jeroen raises, as it is currently it is impossible to reliably install archived packages because their dependencies have since been updated and are no longer compatible. (Even if it passes checks and installs, we have no way of knowing if the upstream changes have introduced a bug). This information would be relatively straight forward to capture, shouldn't change the way anyone currently uses CRAN, and should address a major pain point anyone trying to install archived versions from CRAN has probably encountered. What am I overlooking? Carl On Wed, Mar 19, 2014 at 11:36 AM, Spencer Graves < spencer.gra...@structuremonitoring.com> wrote: > What about having this purpose met with something like an expansion > of R-Forge? We could have packages submitted to R-Forge rather than CRAN, > and people who wanted the latest could get it from R-Forge. If changes I > make on R-Forge break a reverse dependency, emails explaining the problem > are sent to both me and the maintainer for the package I broke. > > > The budget for R-Forge would almost certainly need to be increased: > They currently disable many of the tests they once ran. > > > Regarding budget, the R Project would get more donations if they > asked for them and made it easier to contribute. I've tried multiple times > without success to find a way to donate. I didn't try hard, but it > shouldn't be hard ;-) (And donations should be accepted in US dollars and > Euros -- and maybe other currencies.) There should be a procedure whereby > anyone could receive a pro forma invoice, which they can pay or ignore as > they choose. I mention this, because many grants could cover a reasonable > fee provided they have an invoice. > > > Spencer Graves > > > On 3/19/2014 10:59 AM, Jeroen Ooms wrote: > >> On Wed, Mar 19, 2014 at 5:52 AM, Duncan Murdoch <murdoch.dun...@gmail.com >> >wrote: >> >> I don't see why CRAN needs to be involved in this effort at all. A third >>> party could take snapshots of CRAN at R release dates, and make those >>> available to package users in a separate repository. It is not hard to >>> set >>> a different repository than CRAN as the default location from which to >>> obtain packages. >>> >>> I am happy to see many people giving this some thought and engage in the >> discussion. >> >> Several have suggested that staging & freezing can be simply done by a >> third party. This solution and its limitations is also described in the >> paper [1] in the section titled "R: downstream staging and repackaging". >> >> If this would solve the problem without affecting CRAN, we would have been >> done this obviously. In fact, as described in the paper and pointed out by >> some people, initiatives such as Debian or Revolution Enterprise already >> include a frozen library of R packages. Also companies like Google >> maintain >> their own internal repository with packages that are used throughout the >> company. >> >> The problem with this approach is that when you using some 3rd party >> package snapshot, your r/sweave scripts will still only be >> reliable/reproducible for other users of that specific snapshot. E.g. for >> the examples above, a script that is written in R 3.0 by a Debian user is >> not guaranteed to work on R 3.0 in Google, or R 3.0 on some other 3rd >> party >> cran snapshot. Hence this solution merely redefines the problem from "this >> script depends on pkgA 1.1 and pkgB 0.2.3" to "this script depends on >> repository foo 2.0". And given that most users would still be pulling >> packages straight from CRAN, it would still be terribly difficult to >> reproduce a 5 year old sweave script from e.g. JSS. >> >> For this reason I believe the only effective place to organize this >> staging >> is all the way upstream, on CRAN. Imagine a world where your r/sweave >> script would be reliable/reproducible, out of the box, on any system, any >> platform in any company using on R 3.0. No need to investigate which >> specific packages or cran snapshot the author was using at the time of >> writing the script, and trying to reconstruct such libraries for each >> script you want to reproduce. No ambiguity about which package versions >> are >> used by R 3.0. However for better or worse, I think this could only be >> accomplished with a cran release cycle (i.e. "universal snapshots") >> accompanying the already existing r releases. >> >> >> >> The only objection I can see to this is that it requires extra work by >>> the >>> third party, rather than extra work by the CRAN team. I don't think the >>> total amount of work required is much different. I'm very unsympathetic >>> to >>> proposals to dump work on others. >>> >> >> I am merely trying to discuss a technical issue in an attempt to improve >> reliability of our software and reproducibility of papers created with R. >> >> [[alternative HTML version deleted]] >> >> ______________________________________________ >> R-devel@r-project.org mailing list >> https://stat.ethz.ch/mailman/listinfo/r-devel >> > > ______________________________________________ > R-devel@r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-devel > -- Carl Boettiger UC Santa Cruz http://carlboettiger.info/ [[alternative HTML version deleted]] ______________________________________________ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
