reproducibility wrt CRAN vs Debian binaries of packages? about rocker

[eddelbuettel]

@cboettig Care to explain why is this an issue ticket and not an email?

This is a meta-issue that has little to do with tweaking of the code in rocker, at least for the scope I consider reasonable.

FWIW I needed to set up a box with a (particular) node version to process the particular twitter bootstrap and bootswatch combination that my site uses. I got there without too much trouble by using an older Debian release, and the Debian "snapshot archive" which keeps (approximately) every version of every published package.

I got that done within maybe fifteen minutes but there were still some gotchas because invariably some version of something did not quite work -- I actually first tried Ubuntu as its bi-annual release cycle got me closer to the time point I wanted. Turned out that in this case not all required packages could be restored from the corresponding Ubuntu releases. But it worked via Debian.

I consider recreating such a setup to be out of scope for rocker and would like to close this.

[cboettig]

@eddelbuettel I opened this a ticket with a question tag because I saw it as relevant to the design strategy employed in the dockerfiles (e.g. should Hadleyverse stick with primarily installing packages from the pre-built binaries instead of installing everything from CRAN to increase the stability of the build).

Likewise I am thinking about how I phrase documentation or discussion about the project: is it the goal of the project to write Dockerfiles that are most likely to be able to compile in the future (e.g. by trying to select the most stable sources), or is that not worth the tradeoff against providing the most recent material?

Lastly, I just tend to use issues of the relevant project rather than emails to discuss questions I see as related to the project even though they are not yet actionable tickets because it keeps this information in one place, making it easier for me to find it later and easier for others to weigh in on planning goals. I realize that workflow isn't for everyone, so apologies for not discussing that sooner. Happy to close this out and continue any discussion on email. Thanks for checking in on the scope issue.

[eddelbuettel]

I am not the biggest fan of inflationary use of GitHub tickets. They live on somebody else's server, I can't grep them etc pp. I actually find them hard to use and search, outside of replying to the very most recent one.

Email is not perfect, but it has worked quite for a lot of open source software development.

I'll get of your lawn now.

And lastly, as I am not a co-author on your "reproducibility and Docker" paper, I have the privilege of not being too concerned with random access to random code at some random point in time past. My answer to that is indeed that it is the responsibility of the respective code's author(s) to ensure this, maybe by providing a frozen Docker image at time of publication.

We have a hard enough time making all this work for the here and now with the 'tip' of various repos, and not add the additional burden of going back to user-chosen random points in the past.