Skip to content
This repository has been archived by the owner on Sep 20, 2022. It is now read-only.

JupyterLab and possible upstream contributions #6

Open
BertR opened this issue Aug 31, 2021 · 4 comments
Open

JupyterLab and possible upstream contributions #6

BertR opened this issue Aug 31, 2021 · 4 comments

Comments

@BertR
Copy link

BertR commented Aug 31, 2021

Hi,

this looks really interesting! Are there any plans to upstream this to https://github.com/jupyter/nbgrader/ ?
Will this target Jupyter classic notebooks or JupyterLab as well?

Tagging my co-workers for visibility @perllaghu @jstix

@jgwerner
Copy link
Member

jgwerner commented Aug 31, 2021

@BertR Thanks for the ping 👍

Yes, we do plan on opening this up so that someone could incorporate the code into the jupyter/nbgrader project if they chose to do so. We are doing everything possible to maintain compatibility with the upstream nbgrader RESTful endpoints but are not sure we can maintain 100% compatibility moving forward.

This Formgradernext effort consists of three parts:

  • Formgrader handler: provide a custom handler to serve a custom React application to replace the existing Formgrader UI. The user/admin has the option to opt-in to use the Formgrader (a.k.a. Formgradernext) or continue to use Formgrader classic (assuming both extensions are enabled).
  • New Formgrader frontend: this is a lift-and-shift replacement of the current Formgrader UI. The effort consists of primarily porting Formgrader to a React application (frontend only) to decouple this frontend from the nbgrader code base while maintaining compatibility with the nbgrader API. This frontend code-base is private for now since it's still being stabilized but should be public within the next couple of weeks. The assets are available via our CDN, however.
  • New client extensions: this effort updates the JupyterLab extensions to replace the current Create Assignments extension available with nbgrader. The rest of the extensions, such as Submissions, Fetches, etc could be simplified a great deal to enhance the user experience, so are probably going to create new extensions for this purpose instead of providing a wrapper using the existing classic extensions for JupyterLab.

As a side note we have been doing some work for the last few months with @gzuidhof using Starboard Notebook and as mentioned above would like to do the same with other interfaces. (There is a preview here if you are interested in checking it out). This effort started several months ago and was a way for us to leverage Pyiodide with a Jupyter-compatible environment + nbgrader. Once we have the extensions developed for JupyterLab it should be simple enough to integrate with JupyterLite and friends.

@jgwerner
Copy link
Member

By the way, we do have another project that improves performance when grading is available in the illumidesk/async-nbgrader repo. However, this was a short-term solution. We are currently refactoring the auto-grading services to work with a more traditional queue-based system using Kubernetes jobs.

@BertR
Copy link
Author

BertR commented Sep 1, 2021

That sounds great @jgwerner

Feel free to bring up suggestions on jupyter/nbgrader that would drive this forward.

We do run our hosted platform on Kubernetes as well, so autograding using Kubernetes jobs is definitely something we'd be interested in contributing to!

As you know we've started by moving the exchange into a REStful service (edina/nbexchange)
and have been thinking about similar steps for the gradebook. The latter would be so we can more easily
accommodate multiple markers on a course.

@jgwerner
Copy link
Member

@BertR a quick update here (apologies for going dark but decided to take a mini-break 😄 ). We have a developer now that is creating grading service using a more traditional queue-based solution using AMQP (using RabbitMQ) + Argo. We felt like this was the best mix of providing something that was compatible with the existing nbgrader system but also is flexible enough to use other graders if needed, such as otter-grader.

An alpha version should be ready within the next few days so we could share code with you to get your feedback. As far as the edina/nbexchange project goes it looks promising but decided to start creating our own DB schemas instead since we needed too many changes when compared to the current nbgrader schema. We also may opt on moving to something more no-sql-y (e.g. MongoDB) since it would allow us to simplify the DB updates in the future for things like updating tables for new content types, etc.

Have you ever tested otter-grader?

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants