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

Package a session (basic) #6

Closed
nuest opened this issue Jul 20, 2016 · 3 comments
Closed

Package a session (basic) #6

nuest opened this issue Jul 20, 2016 · 3 comments
Assignees
Labels

Comments

@nuest
Copy link
Member

nuest commented Jul 20, 2016

Create a small session (load few packages, including one from CRAN but not in base packages) and create a Dockerfile that is as close as possible to recreate that session.

Based on sessionInfo()$running we have a mapping from running string to base image. In our case all running strings map to rocker.

Also check devtools::session_info(), could be useful to determine installation source.

Open questions:

  • how can we fill the MAINTAINER field?
@nuest nuest added the feature label Jul 20, 2016
@nuest nuest changed the title Package a session Package a session (basic) Dec 12, 2016
@nuest
Copy link
Member Author

nuest commented Jan 3, 2017

Could be useful to "save" the Dockerfile to a connection (allowing file, stream etc.), see discussion at r-lib/xml2#158

@MatthiasHinz
Copy link
Collaborator

MatthiasHinz commented Jan 17, 2017

Workflow: Package a session

  1. Analyze local sessionInfo:
    a) which base packages are attached?
    b) which other packages are attached? (and need to be installed?)
    c) which other packages are loaded via namespace and not attached? (and need to be installed?)
  2. For the non-base packages (1b and 1c), determine system dependencies (use sysreq-package or shiny dependencies)
    --> RUN apt-get update (evtl. mit quiet parameter -qq)
    --> create RUN instructions(s) that install system dependencies with apt-get
  3. For the non-base packages (1b and 1c), determine how to install them in R
    • if pkg$repository IS CRAN --> use install.packages("..")
      • How shall we determine the CRAN-mirror? / which default should be used?
    • (later) if pkg$RemoteType IS GitHub --> use devtools::install GitHub (devtools::session_info() can also be used for this, but the required information seems to be available in normal sessionInfo() as well.)
    • consider using remotes-package if useful https://github.com/r-pkgs/remotes
    • [...]
      --> create RUN instructions(s) with Rscript -e
  4. Start R with preloaded and attach libraries according to sessionInfo
    • This seems to be rather tricky since R -e and R -f will alsways terminate after batch execution (also does not work with the --interactive flag). The only way to restore an interactive session with required libraries seems to be defining a Rprofile.site file and setting R_PROFILE environment variable to its location (--> ENV instruction)
    • The R_PROFILE file must contain a .First-function which
      • attaches required packages using require(...) (or library)?
      • load namespaces via requireNameSpace()
        --> create instruction CMD ["R"] at the end of the Dockerfile

Further functionality:
I. A package test creates a local R session and a dockerized R session and compares both sessionInfo objects (package names, package versions(?), R versions, locales(?), platform(??) ... others)
II. (maybe later) containerit may perform test-builds and check if all necessary packages are correctly installed can be loaded


I tried to sketch up the general workflow I want to implement. Please comment on this @nuest

@nuest
Copy link
Member Author

nuest commented Jan 18, 2017

Regarding 3.:

  • Instead of install.packages(..) we can utilize littler.
    The way to install packages should depend on the used base image. If we use an rocker/r-ver (or descendants verse, tidyverse etc.) base image, then use littler. If we use another base image (e.g. debian, then stop with and error message that this base image is not supported.
  • CRAN-mirror: that should already be configured in the base image. In case somebody uses another base image, we should have a utitlity method add_cran_mirror("mirror url") (better names welcome) that creates the required RUN command.

Regarding 4.: That is not necessary at the moment, but is a nice idea - moved it to #37. The script that actually does something in the container must load the packages. For your testing, please add a simple R script that library-loads the packages.

Regarding "Further I.": Do check package names and versions, check R version, check locale. Do not compare platform or other things as of now.

Regarding "Further II.": if you think of useful future tasks, please add an issue.

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

No branches or pull requests

2 participants