search

astronomy-commons / genesis-images

Customized JupyterHub and Jupyter images for Genesis Platform deployments
MIT License
1 stars 2 forks source link

Add AXS to the genesis-notebook Dockerfile #1

Open mjuric opened 4 years ago

stevenstetzler commented 4 years ago

I am working on this in branch axs-integration, where you can see the current set up in jupyter-axs (I'm using git lfs right now, so you can't preview files on that branch, you'll have to clone the repository and checkout the branch).

@mjuric could you explain the use of these lines: https://github.com/astronomy-commons/genesis-images/blob/master/genesis-notebook/Dockerfile#L36-L47 I am wondering if they are necessary or what you ran into that requires that. Additionally, looks like you are pulling files from your own site here: https://github.com/astronomy-commons/genesis-images/blob/master/genesis-notebook/Dockerfile#L13-L15. Should we store those somewhere else?

stevenstetzler commented 4 years ago

Additionally, I'm using Git LFS because I needed to build (and include here) my own version of AXS compiled with Kubernetes support. It would be great if we can replace this with downloading a distribution of AXS from GitHub. @mjuric @ctslater Did we ever get anywhere with CI for AXS builds / distributions, and are any of the current distributions built with the -Pkubernetes flag? If so, I can replace this right now.

mjuric commented 4 years ago

@mjuric could you explain the use of these lines: https://github.com/astronomy-commons/genesis-images/blob/master/genesis-notebook/Dockerfile#L36-L47 I am wondering if they are necessary or what you ran into that requires that.

I'm using nb_conda_kernels, which makes all conda environments visible in the 'New' Jupyter dropdown menu. This is great if the user creates their own environment -- it automatically becomes visible. Unfortunately, nb_conda_kernels doesn't check whether a kernel has been explicitly installed (with python -m ipykernel install ...), in which case you get duplicates in the list. And since all of our pre-installed kernels are also in conda environments, nb_conda_kernels duplicates all of them (which is very aesthetically displeasing :) ).

The first printf block works around that by filtering out all kernels that are in environments housed under /opt (the system-wide conda install). I got the idea from https://github.com/jupyterhub/jupyterhub/issues/715 .

The second printf block makes the default location for user-created environments be in the home directory, so they survive instance restarts (the default is in /opt/conda, which is on the container's filesystem and is lost when the user's Jupyter server is shut down).

Additionally, looks like you are pulling files from your own site here: https://github.com/astronomy-commons/genesis-images/blob/master/genesis-notebook/Dockerfile#L13-L15. Should we store those somewhere else?

Right, it's bad. I copied this from something I did ~2 years ago -- we should be getting these files from their source locations (https://github.com/fgeller/kt/releases, and for kafkacat I think there's a conda package in conda-forge). File an issue (or fix it here).

PS: I just noticed there's a bug on https://github.com/astronomy-commons/genesis-images/blob/master/genesis-notebook/Dockerfile#L15 -- the chmod at the end should be targeting kafkacat, not kt (a copy-paste error...)