The viewer seems pretty straight forward to install with some minor modifications to our fork, but the installation steps for the ‘grader-xblock’ raises some concerns that I was hoping to get some clarification on if possible.
Regarding the grader xblock here are my general concerns:
The description of the plugin states that it is generating docker containers for each student accessing notebooks, Does tutor support this? i know docker doesn’t tend to like nested containers, and the setup steps appear to require an install of docker-ce, so i’m not sure if there are additional steps needed to utilize this xblock within tutor, or if this is just allowing the plugin to execute in the parent docker environment.
the following two items may be better asked elsewhere, but in the event anyone knows off hand or has successfully installed the jupyter-edx-grader-xblock in tutor:
During the installation there appears to be a migration utilizing ‘… cms migrate settings=aws’ is this signaling a dependency on amazon web services, if so this work order may be over before it started.
Referencing the following issue on the tutor site from earlier this year which appears to have terminated without a conclusion after the creator was testing something (which is normally a good thing right? …optimism…):
https://github.com/overhangio/tutor/issues/84
the xblock was at that time just releasing with edx - hawthorn support which appears to also be backwards compatible. but what about the future… Again, this is probably better asked elsewhere, but does anyone know off hand if this is supported by the ironwood release?
If it helps, My current environment is utilizing:
Ubuntu 18.04
Tutor 3.3.4
Hi @crivet! I’m terribly sorry about my lack of response, I was on holiday for most of the month.
I think you understand the issue that is at stake here: the xblock needs to be able to spawn containers. Since the xblock runs inside the LMS runtime, the docker containers need to be launched from inside docker. This is quite possible, and thus (theoretically) supported by Tutor, but it does require a little bit of work.
If you ask me, I’m not a big fan of the design decisions that went into this xblock. IMHO it would make better sense that the xblocks communicates with a server that would itself be responsible for remotely launching the containers. Many people are interested in having a fully functional Jupyter XBlock, so maybe someone could do a complete rewrite?
The “aws” settings were the settings used by edx.org for deploying to production prior to Ironwood. They were later renamed to “production”. They still point to many AWS services, such as S3, but Tutor takes care of overriding the right settings so you don’t have to rely on AWS. You should be able to safely replace “aws” by “tutor.production” in all deployment instructions.
Thanks for the information @regis , and don’t worry about the delayed response. Everyone needs a vacation.
for record keeping i’ll share my experience:
I was able to get the ‘viewer’ plugin though it did require additional changes to the edx-repository to add additional urls, and allow at a minimum ‘same-origin’ request policies to allow the rendering of the jupyter notebook. (not ideal but functional)
For the ‘grader’ variant, I ended up shying away from installing this and went with an alternative ‘colab_xblock’ which links to Google’s new Collab app, as this one just links to Jypyter notebooks hosted in a google drive environment instead of generating an abundance of containers.
My philosophy about this is quite different though. Considering things like nbviewer are easily available, and small Jupyter notebooks can be rendered directly in Github, it seems unnecessary to add load to your server to accomplish this.
As for an editor, we worked around this by using the datacamp-light library for coding exercises in the browser. We will use this to scaffold the user’s coding knowledge and then it’s up to them to make it work in Jupyter.
Reasons why I like this better:
Lots of schools like to give their students a Jupyter environment out of the box. I believe this does a disservice to the students because they don’t learn to manage their own local environment. How many companies have a tech team just to support data scientists?
Embedding vanilla Jupyter won’t give the students the opportunity to customize their own environment (preferably via Conda). This is arguably a very important learning experience and teaches things like dependencies, channels, and portability/reproducibility of code.
For most practical data science coding a small docker container isn’t ideal for students to practice. Datasets will load slowly, you will have to manage the RAM tightly, etc. You couldn’t practically have students do things like hyperparameter tuning without them consuming huge server resources.
Some organizations may not like the idea of making their training notebooks public, but that’s data science right?
A web-based alternative like Colab or Deepnote (which allows live collaboration) seem better options.
