More elegant solutions to copying repo to container/image...?

[brooksambrose]

@cboettig Thanks for your response at #15 and don't want to get that convo off track.

I wonder if there is a more elegant solution to using a Dockerfile with binder just to copy a user's repo to the image. Better would be to copy to the container or volume map, but sticking in the vein of the current "data in the image" solution:

Clone the repo as NB_USER in a RUN command during build using a --build-arg to pass in the repo url from the jupyter-repo2docker environment. @yuvipanda would this be more parsimonious than the current solution to get the repo into the container? Unfortunately the Dockerfile would come with, but that would lend some transparency to what the image is, which is currently lacking from the whole process anyway.

So, if:

ARG REPO
RUN git clone ${REPO} ${NB_USER}

Were added say to a rocker/binder base image, and jupyter-repo2docker were updated to take a --build-arg (which would I hope trigger a rebuild if the argument changes) then users could add the simplest Dockerfile without having to hand code copying the repo and changing permissions:

FROM rocker/binder:3.4.2

It would be great if something like that were enough to use a binder as the repo + curated images concept. This isn't hard, but it's also fairly complicated given the ease of use of the other jupyter-repo2docker conventions:

# Make sure the contents of our repo are in ${HOME}
COPY . ${HOME}
USER root
RUN chown -R ${NB_UID} ${HOME}
USER ${NB_USER}

I'm not onboard with Consider phasing out Dockerfile support, because Docker seems too important for general consumption to sweep under the rug.

[cboettig]

Right, I think we should just have the block

COPY . ${HOME}
USER root
RUN chown -R ${NB_UID} ${HOME}
USER ${NB_USER}

built into the rocker/binder Dockerfiles here to begin with. I believe that's what the default Dockerfile already does in binder, so it makes sense we copy that behavior. @yuvipanda is there a reason we haven't done this with the Dockerfiles here?

(of course it's a pity Docker doesn't support a more elegant handling of this / of non-root user permission model in general, but that issue is above my pay grade)

[cboettig]

pinging @yuvipanda Should we add the above to these Dockerfiles? This is necessary to get the install.R behavior shown on https://github.com/binder-examples/dockerfile-rstudio to actually work, right? Should we also add the RUN call to run any install.R script it finds?

Thanks!

[cboettig]

Not sure what I was thinking, clearly COPY has to be done in the repo's Dockerfile and not here. Sent a PR to add it to the binder-examples/dockerfile-rstudio, which was missing the chown commands.