-
Notifications
You must be signed in to change notification settings - Fork 9
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
example which should use only MRAN #8
Conversation
since paper includes commands that read the git commit info
Thanks again, I'm really grateful for your help with these experiments, happy to try anything that makes this process simpler! Looks like the COPY method had a complication, in https://circleci.com/gh/benmarwick/mjbtramp/154 I see I've gone back to |
The error (It's hard to be sure, because the error isn't on the most recent commit and the circle.yml is pulling the Dockerfile from the master github, so I don't know what Dockerfile that circle build used...) It would be a bit easier to debug if we use the COPY and edit the circle.yml to just build from the local Dockerfile and not pull git (at least I think it would). |
Ah, re the installing from CRAN, you need to do: && R -e "options(repos='$MRAN'); devtools::install('mjbtramp', dep=TRUE)" (like so), or otherwise you need to echo the Note that once you set repos with Basically I think this is a devtools bug for not passing the repo arg down, but arguably setting this via options is better anyway. |
Thanks, I've got it back to use It seems like the I added an Where is the rest of the github repo? |
I've added you as a collaborator in case you want to try some quick edits to the Dockerfile. |
Ah, I bet that is because you are giving the docker build command the address of the remote Dockerfile. Recall |
I think the COPY method should work with the above fix, but not sure if it's truly any better than git clone in the Dockerfile. One last possible problem for the COPY is that I think circl CI does only a shallow clone of the repo, so not sure of that will cause the git2r cmds you have to fail... |
Thanks, yes, that seems to have fixed it on circle, using This is making me think more seriously about taking a break from packrat and using MRAN/checkpoint as my precaution against breaking updates from packages. Thanks again for taking a look here! |
Thanks for being willing to experiment, as always! I do kinda wonder if the version-tagged images, e.g. Having MRAN preset in the Dockerfile would avoid the gotcha of doing The expected workflow then might be to do most regular computing on the Thoughts @benmarwick @hadley? |
Yes, I think that's a good idea. Having Setting to a specific date would be very handy also. For example, if I start a new @rstudio project, it would be great to be able to get the date of the These options would certainly save me a bit of fussing around. But perhaps I'm out on the long tail of R users, with my RStudio projects having half-life of well over a year (and so typically spanning 3-4 minor releases of R, and sometimes major changes in packages)? |
Thanks, this is very helpful! Come to think of it, I'm not sure I've ever published a paper with non-trivial amount of code in the space of a single R release myself... That's an important added wrinkle. For a faster writer whose paper spans only 1-2 minor releases of R, it might be feasible to just lock that project to a particular R version and date and stick with those versions for the duration of the project. For GitHub dependencies, one would have to do something like: installGithub.r -u FALSE hadley/xml2@86f89395c0e4dc48e854b8aa8f21fec2a6746f4a (the The date could be the date the project 'started' (see below), though it might be simpler to just use the last tagged version of R (with the MRAN last date for which that version was current). This would suggest that we drop the For people with longer research half-lives, that's a great question, which I haven't actually given enough thought to. My practice so far has been to keep the project current; i.e. I've been developing on I would imagine switching the Dockerfile for such a project from On custom dates: A user could pin MRAN to an arbitrary date if they build the docker stack manually; e.g. clone a copy of the |
Don't feel compelled to merge; just an example of the fix I mentioned in #7.
Also I switched from the
git clone
command to usingDocker COPY
, which will build the Docker image relative to the local sources instead of the github repo; (e.g. Circle-CI build should pass before merging now, unless I messed something else up).Not sure if you have a preference one way or the other; normally having
git clone
in a run command can be nice if you like Docker's ability to cache build layers (having a COPY command breaks the cache; since Docker doesn't know if the file being copied has changed), but if you aren't building locally then it probably doesn't matter. Also I deleted.dockerignore
since you actually want the.git
dir available for thosegit2r
commands at the end; (wasn't a problem when usinggit clone
since that gave you.git
anyhow).Also I switched from
tidyverse
toverse
since it includesbookdown
and friends already and thus the image will build faster; feel free to drop that back totidyverse
though. Either way it should pull all R packages from MRAN now.