Port the notebook extensions to JupyterLab

[fperez]

This is so we can discuss whether this is the right path to follow for nbgrader, I'm not 100% sure yet but at least we can come to a decision here...

We're still using nbgrader at Cal quite a bit, and as I consider moving the students more to JupyterLab as their "daily driver", the absence of the student-facing extension for submitting notebooks is becoming a more relevant issue.

Curious what @jhamrick @ellisonbg think in this context - how realistic would it be to put some cycles into porting the extension? This is more of an nbgrader than a Lab issue, but it's turning out to be kind of a blocker to our use of Lab by default (which I really want to do :).

CC @jasongrout @ian-r-rose as per recent discussions on blockers and extensions...

[fperez]

ps - forgive me if it's been discussed here already, I did a search and didn't find it but feel free to point me to the right location.

[ellisonbg]

Fernando, I have never used the student facing extension. Can you describe exactly what features you are wanting for them? Would be great to help you be able to switch to lab...

On Wed, Aug 29, 2018 at 6:27 PM Fernando Perez notifications@github.com wrote:

ps - forgive me if it's been discussed here already, I did a search and didn't find it but feel free to point me to the right location.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/jupyter/nbgrader/issues/1006#issuecomment-417159499, or mute the thread https://github.com/notifications/unsubscribe-auth/AABr0NiNEmc1IG3BDiaWSmK2LRiAARQzks5uVz9kgaJpZM4WSnqV .

-- Brian E. Granger Associate Professor of Physics and Data Science Cal Poly State University, San Luis Obispo @ellisonbg on Twitter and GitHub bgranger@calpoly.edu and ellisonbg@gmail.com

[fperez]

It's the notebook validation button in JS, that gives this kind of feedback:

It's really just a thin layer atop the cmd line validation, so we're considering telling the students to run it at the cmd line... But I was wondering if anyone had thought about porting it over to Lab.

[jhamrick]

I unfortunately don't have the cycles to work on porting this over, but I agree it is something that should probably be done...

[murhum1]

Might do some work on this - thought I'd start by trying to bring the assignments tab and maybe the notebook validate button to lab side. I'll update once (if) I get anything meaningful done!

[perllaghu]

What would be really useful is to get the assignments [and exchange] code and the formgrader code to be written in the same way, using the same style & idioms: they were written separately, and are very different.

I know that jupyterlab is all angular & typescript in the UI, so there's a chunk of work to just move from javascript to typescript!

(if you can also have space in your thinking for making the exchange a proper API, rather than assumed to be copying files on disk, that would be awesome [it's an outstanding piece of work that was raised at the Edinburgh hackaton... however we've been side-tracked by work & an impending new academic year....])

.... but absolutely: getting nbgrader into jupyterlabs would be fanTASTic!

[pdeitel]

Just checking whether there are more updates on this.

[rkdarst]

I don't think so, last I saw was a rough proof of concept embedding a nbgrader view into a side panel - no time to do more, too much other stuff. I will ping @murhum1 in January to see how it's going, maybe the new year will bring some more time.

• Richard

[pdeitel]

Since it's now March, just thought I'd check in again.

[jasongrout]

I don't know of any update, but since this brought this to the top of my inbox, I'll reply to a comment earlier:

I know that jupyterlab is all angular & typescript in the UI, so there's a chunk of work to just move from javascript to typescript!

JupyterLab is typescript and Lumino, but you can implement extensions in straight javascript if you like.

[Lawrence37]

Hello everyone. @aalmanza1998, @lxylxy123456, @rkevin-arch, and I will be porting the nbgrader UI to JupyterLab as part of a project for integrating nbgrader with Kubernetes and JupyterLab. We are wrapping up the Kubernetes portion (see jupyterhub/zero-to-jupyterhub-k8s#1556) and starting the JupyterLab part. We hope to provide periodic updates on our progress.

Before we dive too deep, we'd like to gather comments and pointers from the community. Your input will be much appreciated!

---

Might do some work on this - thought I'd start by trying to bring the assignments tab and maybe the notebook validate button to lab side. I'll update once (if) I get anything meaningful done!

@murhum1 Sounds great! Any updates?

[TRM13]

Thank you very much @aalmanza1998, @lxylxy123456, @rkevin-arch. I've "sidegraded" to Notebook so I can do NBgrader but the Lab interface is my favorite by a large margin. I look forward to kicking the tires on your releases. I really like the idea of using Kubernetes for isolation with NBgrader. Thanks again

[perllaghu]

Some thoughts, observations, ..... and questions!

Are you thinking of writing another nbgrader, to be labs-compatible, or writing parallel extensions to enable functionality in either interface? By this, I mean if I switch from /tree to /lab, will I see the same assignments, use the same validators, and configure things the same way... or will they be different?

Write tests. Lots and lots of tests. Our own nbexchange release doesn't have a master branch yet because we don't have enough tests! (If you're really brave - go for a test-driven development environment: you know how the various components currently work - so you can write tests to check them, and then code to pass the tests)

Don't paint yourself into a corner: make sure your exchange is pluggable* (see the afore-mentioned PR for that in the current system). Are there any other aspects that can [should] be abstracted out?

Documentation: It's horrible to write, but ensure that either the existing docs remain valid for the process, or that you have it covered.

Will any of the the areas you'll work in, for lab-mode, actually benefit from improvement in both interfaces, for the code-base as a whole?

[*] To me, having the Notebook App talk to an abstracted API makes even more sense in a K8 cluster: why tightly couple the exchange to the hub when you're in a cloud?

[Lawrence37]

We want to add a UI (labextensions) to nbgrader for JupyterLab and use the same back-end. The assignments, validators, configuration, etc. will be the same. I see that there are tests for the nbextensions. We will write similar tests for the labextensions. We will also write documentation on how to install the labextensions and use nbgrader with the JupyterLab interface.

Don't paint yourself into a corner: make sure your exchange is pluggable* (see the afore-mentioned PR for that in the current system). Are there any other aspects that can [should] be abstracted out?

The ngshare exchange uses the same pluggable exchange as nbexchange. I hope this encourages the adoption of the pluggable exchange into nbgrader. The JupyterLab part of our project is probably independent of the exchange back-end, so there shouldn't be a problem with compatibility.

Will any of the the areas you'll work in, for lab-mode, actually benefit from improvement in both interfaces, for the code-base as a whole?

At this point, I don't have any improvements in mind. We shall see what ideas come up when we port the extensions.

[perllaghu]

We want to add a UI (labextensions) to nbgrader for JupyterLab and use the same back-end. The assignments, validators, configuration, etc. will be the same.

Excellent! (and this will be a superb addition.)

You'll discover that the formgrader code and the assignments code were written by different people (I thought there was an issue about this, but U can't find it) ... feel free to ignore that & make the two halves of the system consistent :)

The ngshare exchange uses the same pluggable exchange as nbexchange. I hope this encourages the adoption of the pluggable exchange into nbgrader. The JupyterLab part of our project is probably independent of the exchange back-end, so there shouldn't be a problem with compatibility.

1. I'd love to see more versions/variations of an external exchange .... it's what keeps these exosystems alive.
2. The one I will note is authentication - not everything will authenticate against the hub. (we don't, for example: we have an external LTI authenticator & then a local cookie )

Will any of the the areas you'll work in, for lab-mode, actually benefit from improvement in both interfaces, for the code-base as a whole?

At this point, I don't have any improvements in mind. We shall see what ideas come up when we port the extensions.

Excellent....

Most of my questions/observations are just to help clarify what you're aiming to do from the outset, and make it harder for "mission-creep" to edge in.

We will definitely be interested in what you come up with, and will be glad you share

[sputnik62]

Looking forward to seeing your work. We at the IBM Skills Network wanted to use nbgrader for a while but we are all in on JupyterLab. Have been since v0.23 or something like that.

[Lawrence37]

Some updates: We are dedicating more time to ngshare than we anticipated, so progress on porting the extensions has been slow. It's looking unlikely that we will finish porting all the extensions, so we will try our best to leave our work in a good state for others to take over. We started work on assignment list, course list, create assignment, and validate assignment. Significant progress has been made on assignment list, and create assignment is nearing completion and has tests.

Here's a look at some of what we have. Ignore the styling issue in assignment list. I manually disabled the CSS for this screenshot because the style is leaking out into JupyterLab.

The create assignment extension looks radically different from the nbextension because JupyterLab notebooks lack cell toolbars. It is possible to emulate the old interface, but it's a bit of a hack. Therefore, we decided to create a new UI which is less likely to be broken by changes to JupyterLab.

[perllaghu]

This is AWESOME. The fetch and release are server-side components, so shouldn't be too much effort [if any]

Serious kudos for doing this!

[jasongrout]

The create assignment extension looks radically different from the nbextension because JupyterLab notebooks lack cell toolbars. It is possible to emulate the old interface, but it's a bit of a hack. Therefore, we decided to create a new UI which is less likely to be broken by changes to JupyterLab.

Would things be substantially better if JLab supported cell toolbars? Or do you like your new interface better anyway?

[jasongrout]

The JupyterLab Notebook Metadata sidebar allows extensions to contribute custom widgets to control cell metadata. For example, you can see the widgets in there used for the slide metadata or the tags metadata:

Does it make sense to plug into that UX in JupyterLab?

[perllaghu]

The JupyterLab Notebook Metadata sidebar allows extensions to contribute custom widgets to control cell metadata. For example, you can see the widgets in there used for the slide metadata or the tags metadata:

I was about to point to the top toolbar as the place where one sets the cell type... which seems to know which cell it's referring to.

[jasongrout]

We would love to see what you have in the JupyterLab weekly dev meeting. We might be able to give some suggestions or answer questions about how to interface with JupyterLab as well. Just show up and add something to the agenda - we usually create the agenda in the first few minutes of the meeting.

[jasongrout]

I was about to point to the top toolbar as the place where one sets the cell type... which seems to know which cell it's referring to.

Yes, you could definitely add something there too.

One disadvantage to using the current toolbar or notebook metadata panel is that it is hard to see all the cells' assignments at once. With cell toolbars, you can scan down the notebook and see at a glance how everything is set up, and you preserved that in your UX to some extent.

I would imagine that being able to see this information across the entire notebook at once (rather than having to click on each cell individually to check it) is critical to the UX here. What do you think?

[aalmanza1998]

Here's a look at the styled assignment list extension. I still have some bugs to fix and need to write tests.

[Lawrence37]

I've considered adding the interface to the property inspector (metadata panel?), but it's a big step backwards in terms of usability. As you've noted, you must click on the cell to see its properties and only one cell's properties is visible at at time.

I don't have a strong opinion between the cell toolbar and the new interface. This is something nbgrader users should weigh in on.

• Cell toolbar pros: Strong visual link between a cell and its properties; Toolbars scroll with the notebook; See toolbars on all open notebooks simultaneously
• New interface pros: Not cluttered by cells; Independent scrolling is possible; Can be used when another toolbar is enabled (not important if multiple toolbars can be enabled simultaneously)

[jasongrout]

I don't have a strong opinion between the cell toolbar and the new interface. This is something nbgrader users should weigh in on.

@ellisonbg had some comments when we discussed this at the JLab dev meeting yesterday. @ellisonbg?

[lxylxy123456]

We have done some of the work of porting the extensions to JupyterLab, but we are not quite finished. What we have done are documented in https://ngshare.readthedocs.io/en/user-guide-new/appendix/jupyterlab_extensions.html, and the code is in a fork of nbgrader: https://github.com/LibreTexts/nbgrader-to-jupyterlab/tree/lab-common. We hope some one can continue our work on this project.

[jgwerner]

@jasongrout @ixjlyons we'd like to help move this along. @netoisc would do most of the work, he is much more capable than I 😄 . We agree that the formgrader piece is the most complex. How would you suggest we develop the UI's specifications?

[jasongrout]

I haven't used or worked on nbgrader, so I'll let others comment on that. If there are blockers in JupyterLab core, though, I'd suggest opening an issue in JupyterLab or joining our weekly dev meeting to raise the issue for discussion.

[jgwerner]

Thank you @jasongrout! @willingc we were wondering what the best approach is for Formgrader's specifications (assuming you would like to keep that functionality within the UI and assuming no other person/org is helping with these tasks). If you could provide us with some additional guidance then we can take it from there. Some of our initial thoughts are:

• Create and confirm the UX specification (panes, nav flow, modals, etc) based on the excellent work already delivered + Formgrader.
• Confirm the updates for assets (such as moving from bootstrap 3.x to 4.x), or use something else that is better suited for JupyterLab
• Considerations for e2e testing (update selenium-based tests, etc) for all client extensions + Formgrader

If that looks ok then we can open the issues and start work on this next week.

[perllaghu]

what the best approach is for Formgrader's specifications (assuming you would like to keep that functionality within the UI and assuming no other person/org is helping with these tasks).

I would be interested in working out the ratio of UI users to CLI users.

I know that, in my particular environment, all of our users are spawned into a UI.... so any CLI users would need to go through the hassle of launching a new terminal, and running from there.

In terms of functionality - when we were writing the code to make the nbgrader plugin to enable an external exchange, I assembled this: https://github.com/edina/nbexchange/blob/master/docs/nbgrader-exchange-calls.rst

So, in essence, the formngrader UI calls the CLI functions (unlike the assignment_list UI, which calls handler-methods directly.

Having said that.... I find it annoying [and somewhat confusing] that the formgrader server & the assignment_list server work in different ways.... and this may be a good opportunity to correct that, and bring the two servers into line (meaning that, down the line, people writing extensions for them don't have to write things in two different ways)

Confirm the updates for assets (such as moving from bootstrap 3.x to 4.x), or use something else that is better suited for JupyterLab

What is JupyterLab actually coded in? Using the same application tools (bootstrap / flex / angular / vue / whatever ) would make life way easier.

[Sefriol]

Throughout JupyterLab, we are mostly following principles from Google's Material Design when selecting colors. We are not, however, following all of MD as it is not optimized for dense, information rich UIs.

i.e. they have mostly written their own css and components.

https://github.com/jupyterlab/jupyterlab/tree/master/packages/application/style https://github.com/jupyterlab/jupyterlab/tree/master/packages/ui-components https://github.com/jupyterlab/jupyterlab/tree/master/packages/theme-dark-extension/style https://github.com/jupyterlab/lumino

[jgwerner]

they have mostly written their own CSS and components.

That's our understanding as well. So we could help port the existing nbgrader bootstrapped-3-based assets to JupyterLab's standard CSS.

[willingc]

@jgwerner I would open an issue outlining your proposed approach as a RFC (request for comments).

Personally, I am fine with any UI updates as long as the underlying API for the CLI stays consistent. Though I'm not actively using nbgrader so we should cross-post the RFC to the discourse channel and the jupyter in education mailing list.

[Sefriol]

Adding more references: https://jupyterlab.readthedocs.io/en/stable/developer/virtualdom.html https://jupyterlab.readthedocs.io/en/stable/developer/css.html https://jupyterlab.readthedocs.io/en/stable/developer/patterns.html https://jupyterlab.readthedocs.io/en/stable/developer/ui_helpers.html

[jgwerner]

@willingc will do!

[sdyang1729]

Hello, I am just wondering how it is going with porting nbgrader to jupyterlab.

[jgwerner]

Personally, I am fine with any UI updates as long as the underlying API for the CLI stays consistent. Though I'm not actively using nbgrader so we should cross-post the RFC to the discourse channel and the jupyter in education mailing list.

@willingc @BertR we (me and my co-workers) were discussing nbgrader's scope and agree that the underlying API and CLI should stay consistent. It seems to us that it would be better to provide frontend clients in other repos. For example, JupyterLab extensions, VS Code / Theia extensions, dedicated web apps, etc. From this perspective, the current frontend client developed with Jupyter Classic (Jinja2, Bootstrap3, etc) could be moved to its own repo (which could be deprecated in favor of something that has an updated stack) and maintain a list of curated and/or community front end clients in the jupyter/nbgrader docs.

[Sefriol]

Separation might be a good idea if there is desire to use different backend infrastructures. We, at our University, have talked that while nbgrader does provide "good enough" solution, it's very far from perfect one. JupyterHub should be a resource platform in the end and all of the other functions should be provided by other services.

Grading should be done with service that actually provides interactive and student driven grading (or atleast have a possibility for it. i.e. now the grading is done when instructor says so), secure execution environment for grading, in addition to sufficient tools against plagiarism. List goes on.

Course management and grade storage should also be a separate and secure system, not tied to JupyterHub at all (Plugable exhange actually tries to solve this a little bit and there some ways to migitate this problem a little bit). Usually some exercises are better to be provided by other systems, so there should be another system handling the course as well. Nbgrader is a hackish solution in good and bad. It's all around good enough solution for it's purpose, so at the same time, separating it into different components might provide some value, or none at all.

What I am trying to say that nbgrader is a good product as a whole, but it's individual parts are not that strong on their own. Based on the surveys that we have done to our University Instructors, usually most praise comes towards general features of JupyterHub, not necessarily nbgrader.

And one feature which currently hinders nbgrader down is the lack of JupyterLab UI. Jupyter Notebook UI starts to be really dated compared to many modern tools. One of the key benefits of the system was ease of use, no installations required. JupyterLab UI is the one of the ways to keep this project alive.

[jgwerner]

@Sefriol we agree, the most challenging extension to port from our perspective is the Formgrader since its more of a full-blown web app with its own UI. The other extensions are more easily ported and the work completed by @sdyang1729 seems like an excellent start.

[perllaghu]

Interestingly, formgrader's less integrated to the code that the assignments extension - the formgrader buttons mostly just call the the same api.methods the command-line tools do, whereas the assignments extension is much more direct abot reading/wrting to disk & moving files around

[AnnabellBrocker]

Hey everyone,I was wondering if there are any updates concerning the integration of nbgrader into JupyterLab.

[poiug07]

Any updates or another repos which provide the use of nbgrader in jupyterlab interface?

[perllaghu]

At this time, no..... however we may be looking at it later this year/early next year

[shalyng]

Interested in this as well and with it now being early next year, curious if there's been any more headway.

[damianavila]

Status update: https://github.com/jupyter/nbgrader/issues/1335#issuecomment-994088125

[davidbrochart]

I've seen some work has been started on porting nbgrader to JupyterLab, but the documentation link is broken and the last commit of the forked repository is from 2020. @lxylxy123456 would you recommend taking over your work, or just starting from scratch?

[lxylxy123456]

@davidbrochart

I think @Lawrence37 or @aalmanza1998 may better answer your question. They contributed most commits in the lab-common branch.

As for documentation, see https://ngshare.readthedocs.io/en/ecs193-final-report/appendix/jupyterlab_extensions.html (it has been a long time since I worked on the project, so I am not sure why the link breaks).

[Lawrence37]

@davidbrochart Our fork of nbgrader was part of a short-term project that concluded in 2020. We intended to port as much of the extensions as possible and leave them in the hands of the nbgrader community. The code may be a little messy due to our limited experience with JupiterLab and its tech stack, but we managed to make significant progress. Forking or adopting our work is a good option. Of course, you are free to start from scratch if you feel like that is the way to go.

[eliaswimmer]

We are working on a new grader service for JupyterHub/Jupyterlab, I hope we will soon be able to publish it.