-
Notifications
You must be signed in to change notification settings - Fork 273
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
Mapping out the component dockerfiles and their dependencies? #1
Comments
Agreed on Debian as well as Ubuntu. Another open question how to signal "super and sub-set", ie container re-used by others, with alternates when we have two alternates. |
Nice to see that you are thinking about ways to combine R & docker. I'd like to join the discussion, if you don't mint. What about having many small & modular images and add a way to indicate with ones are supposed to be used by end-users ('exporting' images would also by very R-like...). I'm thinking about something like having two docker-repos point to this github repo, one which builds intermediate images, and one which build end-user images. From the docker side we have something like
and
From the GitHub side, images can still be arranged according to their actual dependency structure. |
Thanks for joining the discussion. So you are suggesting to (explicitly) build images based on sub-images? I think I only ever started from a (single) image which I then mod'ed. This could work, I guess. Particular docs or examples? |
Not sure if I understand your question correctly. Are you asking if a particular image can be based on multiple images (e.g. combine and image containing debian with r and an image containing debian with latex get an image with debian, R and latex). If so, then no, I don't think that is possible (at least not yet; would be awesome though...). I was just addressing the point that having many images might confuse users (completely independent of how images are build). By having multiple docker-repos, we could indicate which images are indented to be used by users, and which ones are just there to simplify maintenance. Or which ones are designated for R developers, and which ones for R users and so on... |
Let's address this one by one. Your chart already showed six different 'leaf nodes' aka images. But now you say _ having many images might confuse users_. And I agree with that. Where does that leave your proposed idea then? Should we rather concentrate on, say, a handful (at the most) "useful" images: r-devel, r-studio, ... and then let others, or at least other repos, refine this further, say with domain-specific apps? |
Sorry, I should have made it clearer that I was thinking about ways how we could have many images without confusing users. The reason for that was that the first post mentioned that many small and modular dockerfiles might be easier to maintain than a few ones having a lot of redundancy. If we stick to a small number of images however, I agree that maintenance should not be problem and a modular approach is not necessary. |
Okay, following the basic strategy outlined at the top of this issue, I've added Dockerfiles in both Ubuntu and Debian flavors for:
|
Great, thanks for pushing the cart! Personally, I find 'r-dev' too confusingly close to 'r-devel'. Maybe we should just define 'r' to be 'r-dev' and maybe (if needed) have a more bare-bones 'r-base'? |
Agreed. That has the nice side-effect of focusing people on the most complete image, which is probably most useful to beginners even if it has more software than they usually use, since it avoids having to mess around with installation. I've renamed:
(in both debian and ubuntu flavors) Thoughts? |
That's better. Unless someone finds 'r-base' preferable to 'r'. But we can clarify in a README.md ... |
Yup. So we don't have an image that provides the r-devel pre-release version. When you get a chance, I'd appreciate your input on what should go into the On Thu, Sep 18, 2014 at 3:08 PM, Dirk Eddelbuettel <notifications@github.com
Carl Boettiger |
We've decided to go with three base images:
(in both debian and ubuntu flavors) and then some "use case" ones merging all three plus specific add-ons, e.g.
use cases will be targeted to what we feel the community is most likely to build upon, and won't cover all combinations. Package selection will emphasize packages with non-trivial install (e.g. external library dependencies, long compile times etc). We're open to proposals of particular use case through this repo's issue tracker. Finally, we'll develop a wiki for tutorials on how to install additional packages on ubuntu/debian system (taking advantage of debian-r.debian.net and marutter repos). This will probably emphasize writing Dockerfiles rather than interactive installation (hey, it's easier than writing a .travis file and is better from a reproducible-research standpoint that individual researchers can generate images specific to their needs or needs of their community). |
Currently Implemented as outlined above. Plan is now to deprecate ubuntu images. |
Wondering if we shouldn't do a bit of brainstorming about how best to nest the different Dockerfiles before we get started. It seems like we have an interest in building two trees: an Ubuntu-based one and a Debian based one.
From the Dockerfiles we already have, the current structure of a given tree looks something like this:
This isn't a bad structure, but particularly out near the twigs there's some redundancy and room for shuffling. For instance,
ropensci
has a lot of the compiler/tex dependencies found in add-r-devel (actually it currently has everything in r-devel).swc
could use the largerropensci
as a base (e.g. to share the compile tools, or so that the knit2pdf button on rstudio will actually work).Offering too many images might be overwhelming to users, but smaller more modular dockerfiles might also be easier to maintain. Lots to think about I guess.
The text was updated successfully, but these errors were encountered: