Delete and copy examples directory on every load

[mrocklin]

Currently we keep example notebooks in helm-chart::docker-images/notebook/examples and copy these to the notebook image whenever we make a new image. Then we upgrade the helm chart and users get new notebooks if those notebooks do not conflict with what they had before.

Instead I propose that we pull the examples out to a separate repository, and clone that repository into the user's directory every time we start up a new pod. This would delete the existing examples/ directory and replace it with a clean one that was pulled fresh from github. This is good because it becomes much cheaper to add and remove example notebooks but is bad because it will potentially delete user's files. We would put a loud DO_NOT_STORE_FILES_HERE.md file in the examples directory to try to avoid this situations.

Comments? Concerns?

[rabernat]

This is a good idea. But we definitely want to do some outreach to existing users before implementing it. I am sure I am not the only person who has a large number of in-progress personal notebooks in the examples directory! I would be very screwed at this point if they were deleted.

[mrocklin]

We could also only do hard-rewrites on the existing files for a while, leaving other files intact

[tjcrone]

Currently I am a fan of using lifecycleHooks to populate new user directories, using a git clone which will fail out if the directory already exists, and teaching users to fetch/merge/and/or/reset (not pull) to bring their examples up to date as needed. It helps users become better users of git, and does not risk rewriting anyone's anything.

[mrocklin]

My guess is that this would work well in a small group where you have the ability to educate the user base. For the public deployment we may not have this access. We may also not be able to assume familiarity with git.

…

On Tue, May 8, 2018 at 1:03 AM, Tim Crone ***@***.***> wrote: Currently I am a fan of using lifecycleHooks <https://zero-to-jupyterhub.readthedocs.io/en/latest/user-environment.html#pre-populating-user-s-home-directory-with-files> to populate new user directories, using a git clone which will fail out if the directory already exists, and teaching users to fetch/merge/and/or/reset (not pull) to bring their examples up to date as needed. It helps users become better users of git, and does not risk rewriting anyone's anything. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#242 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AASszFHSZELjG1ea5knyU5oilukrudP7ks5twScPgaJpZM4T1a6G> .

[rsignell-usgs]

It would be great to know that the ./examples directory contained the latest/greatest. When I first started using pangeo I created directories for my own stuff, but perhaps for folks who don't read the doc or see the .md files, adding an empty ./my_examples directory would give them the idea?

[mrocklin]

@martindurant if you're looking for a starter issue with high impact, this would be a good one.

It would also force you to deploy things (which is hopefully now easier) which is something that we'd like to improve, both with documentation and eventually automation.

[martindurant]

OK, happy to take this on:

• move examples to a separate repo
• on startup, copy files to examples/ in the home directory
• make those files read-only, and make an empty READ_ONLY_EXAMPLES.md file or somesuch
• make new, empty directory called something like work/

This leaves open what to do in the case that there is existing material in examples/. I can leave it as it is, only update files so that existing files are left unchanged.

[mrocklin]

This sounds good to me. However I'm a bit concerned about the user experience when working on a read_only notebook file. Does Jupyter complain? What about making a new directory entirely so that we don't conflict with the user's existing code. I don't suppose anyone can convey a name that both conveys that "this is a directory of examples that you should look at but shouldn't trust to be around for a long time" that is also very short?

…

On Thu, Jun 14, 2018 at 4:46 PM, Martin Durant ***@***.***> wrote: OK, happy to take this on: - move examples to a separate repo - on startup, copy files to examples/ in the home directory - make those files read-only, and make an empty READ_ONLY_EXAMPLES.md file or somesuch - make new, empty directory called something like work/ This leaves open what to do in the case that there is existing material in examples/. I can leave it as it is, only update files so that existing files are left unchanged. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#242 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AASszHtwe2I-cyi2JUyWWia3pnJRhPEWks5t8su2gaJpZM4T1a6G> .

[martindurant]

Read-only files are fine. You get File Save Error for <file>.ipynb if you try to save. I notice that there is no obvious indication that the file is read-only, unlike classic notebook which shows a no-save icon.

[mrocklin]

Hrm, I wonder if we can push on JupyterLab to improve the error message there, informing the user that their file is read-only and that they should try Save As...

…

On Thu, Jun 14, 2018 at 4:53 PM, Martin Durant ***@***.***> wrote: Read-only files are fine. You get File Save Error for dask-array.ipynb if you try to save. I notice that there is no obvious indication that the file is read-only, unlike classic notebook which shows a no-save icon. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#242 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AASszP7Ddc6AoO33dqvSygQqNQs12pnpks5t8s1LgaJpZM4T1a6G> .

[rabernat]

It's important to me that the new-user experience when running the example notebooks be as smooth as possible. So file save errors, without any more context, would be best to avoid. One temporary workaround would be to put in big letters at the top of every notebook "THIS IS A READ ONLY NOTEBOOK AND CAN'T BE SAVED"...

Here's an alternative idea...what if, instead of making the example notebooks read only, we tag them with a date on every update? That way the users could play around with them and even save them, but if a new update comes through, it will go into a different filename. Is there a obvious problem with this?

[martindurant]

Actually I like that idea, clone the repo every time and add the dates tot he filenames upon copy (git log -1 --format=%cd --date=short).

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.