Skip to content
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

Open
hlapp opened this issue Feb 28, 2017 · 3 comments
Open

Consider moving to versioned tidyverse dependency #20

hlapp opened this issue Feb 28, 2017 · 3 comments

Comments

@hlapp
Copy link
Member

hlapp commented Feb 28, 2017

It's questionable whether depending on the latest tag of the rocker/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?

@cboettig
Copy link
Collaborator

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 (tidyverse where the optional dependency is installed, though littler itself entered up at r-ver) build but does break builds further down. Of course the latest version (equivalently, the 3.3.2 version currently) will always be vulnerable to changes in R packages that don't break build process (probably most of them), which is why the versioned images are best when reproducibility is primary concern. but for generic user experience I think latest makes sense.

@hlapp
Copy link
Member Author

hlapp commented Feb 28, 2017

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.

hlapp added a commit that referenced this issue Apr 29, 2019
The immediate motivation for this is to fix the apparent unavailability
of quadprog (a dependency of phangorn) in R v3.5.3, the version of R
used in the `latest` tag. However, see #20 and #32 for context.

Closes #32.
@hlapp
Copy link
Member Author

hlapp commented May 10, 2019

This is now implemented for release v0.2.13, see 8002cbf. The Dockerfile on master (corresponding to the latest tag for the image on Docker Hub) remains on latest for the rocker/tidyverse image.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants