Zero-to-jupyterhub-k8s: Best option to auto populate some notebooks within user env

[gsemet]

Hello

Just a few question about the best practices and see what people do around how to populate the user's environment when they starts.

One approach could be to load a shared, readonly volume somehow (NFS, or a dedicated kube mount), but user would need an easy way of "copying" the notebook to their own location so they can change and play with them.

There is also the simpler "read/write shared volume", but that unusuable when some messes with the notebooks.

I use for the moment a "copy on start" approach where I force the checkout of a git project, replacing the content previously made by the user. The notebooks are here, but they cannot keep easily their change. And it can grow a lot, especially with notebooks with lot of diagrams, and so.

My ideal solution would look like:

• user can navigate in a shared tree, readonly.
• they can open to see how a jupyter notebook looks
• if they want to modify the notebook, they would perform a fork (so on github/gitlab they actually, really perform a project fork)
• they can perform their change locally
• when they have made a fix, they can create a mergerequest/pullrequest to the reference project somehow (automatically?)

What is your current approach? do you let people perform their own upload/git clone? Or do we have to rely on the excelent binder project?

[yuvipanda]

We primarily use http://github.com/data-8/nbgitpuller a lot! It works very
well for us, and you can use it with the notebook extension or from the
commandline.

On Thu, Mar 15, 2018 at 3:51 PM, Gaetan Semet [e-mail]
wrote:

Hello

Just a few question about the best practices and see what people do around
how to populate the user's environment when they starts.

One approach could be to load a shared, readonly volume somehow (NFS, or a
dedicated kube mount), but user would need an easy way of "copying" the
notebook to their own location so they can change and play with them.

There is also the simpler "read/write shared volume", but that unusuable
when some messes with the notebooks.

I use for the moment a "copy on start" approach where I force the checkout
of a git project, replacing the content previously made by the user. The
notebooks are here, but they cannot keep easily their change. And it can
grow a lot, especially with notebooks with lot of diagrams, and so.

My ideal solution would look like:

• user can navigate in a shared tree, readonly.
• they can open to see how a jupyter notebook looks
• if they want to modify the notebook, they would perform a fork (so
  on github/gitlab they actually, really perform a project fork)
• they can perform their change locally
• when they have made a fix, they can create a
  mergerequest/pullrequest to the reference project somehow (automatically?)

What is your current approach? do you let people perform their own
upload/git clone? Or do we have to rely on the excelent binder project?

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/jupyterhub/zero-to-jupyterhub-k8s/issues/586, or mute
the thread
https://github.com/notifications/unsubscribe-auth/AAB23pxgoPYV-f85n5CAGmhNa2xJ3TlMks5tevBWgaJpZM4StAEX
.

--
Yuvi Panda T
http://yuvi.in/blog

[consideRatio]

I have also used nbgitpuller and appreciate that a lot for many use cases.

I liked the idea of having a way to provide my students with links and various read-only stuff always up to date, so I also mounted a kubernetes git-volume, that way, no matter if they arrived to the hub with or without a nbgitpuller link, they had access to some common up to date material, such as a list of nbgitpuller links, course overview etc.

[gsemet]

great ! does it work with jupyterlab already?

[consideRatio]

@gsemet almost, you can end up being redirected to the classic view instead of the jupyterlab view, but the stuff will be imported.

I created this issue thinking about that:
https://github.com/data-8/nbgitpuller/issues/36

[gsemet]

will try it next week :)

[yuvipanda]

@gsemet any luck with nbgitpuller?

[gsemet]

No time, too busy ! But yes I feel nbgitpuller would do the job !

[consideRatio]

We are on track / already providing some details about nbgitpuller in docs now, and some work to support it better with jupyterlab that works and breaks often during their development progress. Currently its unstable with opening the targeted file using urlpath/subpath params.

[gsemet]

By the way, I have tried nbgitpuller with jupyterlab, works but does not do the right redirection. Hope this will be supported in a near futur :)

[consideRatio]

@gsemet ah yepp I've battled redirections for a while now... JupyterLab's concept of workspaces is the latest hurdle to overcome for that I think.

I've also opened https://github.com/jupyterlab/jupyterlab/issues/5211 to allow a notebook to contain nbgitpullerlinks relative to the notebook server within JupyterLab.