Pull in features from forks

[nuest]

• silencing the license printing > Hanziness@5580551
• look through https://github.com/blueogive/mro-docker/commits/master
• look through https://github.com/Hanziness/mro-docker/commits/master
• use long arguments: scottstanfield@a4790c7

[Hanziness]

Hi Daniel!

Thank you for picking up my changes! If you're interested, I can chime in with getting the license printing right. The current implementation caused issues with parallel packages (doSNOW for example) that spawned multiple child processes that also printed the license as they started, flooding the terminal. It also broke a package installation for me (I can't remember which one it was, but it was, again, due to the child/slave process also printing at startup).

I borrowed the process check code form the MRO startup script, but I'm thinking of moving these code lines into a separate file and cating them into the startup files, making the Dockerfile less cluttered (not yet sure which would be the better way to do it, though).

I believe my changes have solved the problems I experienced, with the licence still being printed when entering the main R console from the image.

Let me know if I can help and I'll gladly join with a PR! :)

[nuest]

@Hanziness If you'd be willing to open a PR that would be awesome!

[nuest]

@blueogive would you be interested in running us through the main changes in your fork, and maybe combining them with the work by @Hanziness ?

[blueogive]

Sure, I'd be happy to see the forks combined. My changes tried to:

1. Include the Microsoft ODBC driver for SQL Server and the SQL command line tools in the image;
2. Add some Makefiles to support easier build/tag/push cycles;
3. Add a mechanism for the user to specify a custom list of R packages to install within the image at build time without modifying the Dockerfile;
4. Include the Source Code Pro font in the image (an admittedly niche requirement).

Any guidance on which of these items you'd be interested in including in a PR?

[Hanziness]

@nuest Gladly! I'll try to clean up my code a bit and make a PR!

@blueogive While @nuest will make the ultimate decision on this, I believe the third one could be the most handy for users - that could also allow keeping the pre-included package set at a very minimum and allow people to drop in their own dependencies when creating their Docker instances. Maybe separate PRs with these could be great, too - not sure how easy it would be to do that, though :)

[nuest]

@Hanziness Looking forward to the PR! I'm not a heavy user of the image, so happy to welcome features/changes that you need (also re. "will make the ultimate decision").

@blueogive Regarding your changes:

1. Is the ODBC driver also openly licensed? Sounds reasonable addition to the image for me, because MRO users are likely to be in the Microsoft R Stack (which AFAIR is closeley linked with SQL). If the image picks up users, have variants (mro:sql-3.5.1) might become a thing.
2. Makefiles 👍 though IMO the focus should be on making the Docker Hub builds work well (looking forward to what the Makefiles should do)
3. I suggest to use a file install.R for that, akin to repo2docker, so copy that file in and then do RScript install.R - would that work for you?
4. Year, so I'm not sure about that one. What's the reasoning behind it's inclusion?