Consider phasing out Dockerfile support

Custom Dockerfiles are going to be a source of neverending support problems as we make assumptions and requirements about what is present in the image. We already have requirements about JupyterHub version, and will probably develop new requirements over time, such as additional extensions, notebook server version, etc. These aren’t feasible unless we are performing non-optional installation steps in the image ourselves.

Pushing people toward a clear ‘run here’ script that is purely in addition to our own image setup should be hugely more supportable in the long run. Following the well-established pattern of .travis.yml should allow us to cover things much more rigorously while allowing users to perform additional actions, such as build steps or downloads (post-processing on the repo, essentially).

I would consider ~every case that can only be solved by Dockerfiles to be a bug requiring higher-level support elsewhere. The only one that I can’t really see a way to support is building from custom base images. I don’t see how that’s really supportable in the long run, though.

[willingc]

Let’s go ahead and close it. We can open a new issue that limits usage or functionality at a later time.

[cboettig]

Understanding, using, and supporting containerization and the open container standard as a portable compute model definitely seems to have legs in the data science community in both academia and industry. Supporting this standard as a first-class citizen in the binder platform seems like a reasonable goal.

It’s super easy to create plenty of headaches in the existing approach anyway (e.g. try mixing some conda channels with conflicting opinions about system libraries), and tracking down incompatibilities or build failures because someone’s spatial data analysis package needs a different version of the postgis driver or whatnot. If people are bringing their own container then you can reasonably punt on the maintenance issue; while letting people bring containerized solutions from their particular community which is probably best placed to answer such thorny dependency config issues anyhow