Open profLewis opened 4 years ago
What would be great would be that, if someone didn't use the docker, but rather wanted this same consistent setup on top of a base anaconda/Miniconda setup, they could also achieve that through this repo.
By 'someone' here, I mainly mean ISD: they should be able to use this same repo config to set up notebook server with the configuration we want. It also might apply to use by people who (mainly) know what their doing, and don't need to be containerised.
What does that involve:
Of course, isd people could just look at the docker file and manually run what's needed: it's not so hard or complicated.
But it might be cool if either:
Given the main aim here is dockers, option 2 might be better. Some code probably exists to do that. But really you just have to read the file and respond to the keyword: arg, from or run ...
But option 1 would be much easier. Eg put those jupyter setup commands back into a 'postBuild' as we had before, and run the postBuild script from the docker.
I think a consistent setup might be easier to achieve if the base setup were anaconda rather than jupyter, but maybe that doesn't matter, so long as we specify the jupyter and required packages in environment.yml.
Two things:
environment.yml
(most of them will be installed anyway)environment.yml
and then install all those *!#$ extensions would do. It's not that hard to keep two files (proposed script & dockerfile) in sync. This is what was done at Geography (and we also had a tarball of the whole install ;-D)For case 2, might be useful is to update environment.yml
from the "already everything installed" docker container (e.g. run onda env export --from-history > environment.yml
), as that has all the jupyter stuff on it.
Thanks I agree its not hard, o to run from environment.yml just an idea for a bonus feature. No need for any luser instructiions.
why risk inconsistency? Why not call the script from docker or read & run the docker? Its simpler.
The issue with --from-history > environment.yml from the jupyter-notebook container is that it is linux specific — I looked at that yesterday. You can filter it, but not Worth the hassle / chance of messing up. Better to make sure our environment.yml provides everything needed to work from miniconda I think.
This is great and achieve its aim of setting up a core docker that can vibe developed from. The core docker provides the containerised env that should the simplified and consistent student deployment we wanted on their own machines and is not dependent on other aspects of their setup.