-
Notifications
You must be signed in to change notification settings - Fork 2
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
Consider moving to versioned tidyverse dependency #20
Comments
That's a good question, I'd be curious to see what you decide. In some ways, the inevitable build failures from upstream changes should really just be an issue for the maintainer and not really impact your users. Users could continue to depend on your image since they'd still just get the latest successful build from Docker Hub, they just won't be able to get a newer build of the popgen image until the issue is fixed upstream. But that's arguably not any worse than being stuck to an old version. This latest break is a bit more surreptitious than most, since it doesn't break the stack where it is introduced ( |
Good point that the event of a build breaking due to some upstream change doesn't actually hit the user, only the maintainer. I agree it's useful to distinguish user applications prioritized on reproducibility (such as an analysis for a publication) from those prioritized on usability. Speaking for example from the popgenInfo perspective, I think many people looking at those vignettes won't necessarily be running Docker, or know how to run their R analyses out of a Docker container. So I think at least from that perspective it's important to have the Rpopgen container tagged 'latest' reflect the result of a command they can easily reproduce (such as, "upgrade everything to the latest version"). Conversely, it seems to me that that argument would suggest to tie down the tidyverse version for the version-tagged container, because it would arguably be primarily used by people with reproducibility as the driving motivation. |
This is now implemented for release v0.2.13, see 8002cbf. The Dockerfile on master (corresponding to the |
It's questionable whether depending on the
latest
tag of therocker/tidyverse
container is the best idea. While it will perhaps be more reflective of what users have installed (or can have installed if asked to upgrade to the latest versions), it's prone to start failing at some point simply due to upstream changes. See https://github.com/rocker-org/rocker-versioned.Or perhaps the solution is to do that only in our versioned containers?
The text was updated successfully, but these errors were encountered: