We’re looking into requesting an open $5000 grant from NumFocus to have some work on the open source tool scrapbook, a jupyter library from the nteract organization. The grant would be for someone with some knowledge of jupyter messaging (has a rough understanding of display messages) and good python skills who would be interested in a month’s paid work in the open source space. Specifically, the project would be to address some needed work to help get that tool to a 1.0 status, including remote scrap saves (e.g. S3), decoupling from papermill’s IO registry, and some quality-of-life aspects around the API and supported storage translators.
If you’d be interested in joining for such work, please reach out to me (my email should be public on Github) and we can get the application for the grant entered. I’ll be the point of contact for facilitating the grant and the development.
This sounds great - I am definitely in support of it!
We are mimicking the scrapbook glue functionality over in Jupyter Book and MyST-NB (https://myst-nb.readthedocs.io/en/latest/use/glue.html). We’ve tried to use the same Python API and metadata structure under the hood, with the exception that the MyST-NB glueonly stores the display data and nothing else. We were gonna use Scrapbook but realized it was a bit unnecessary given that the “glue” function only took like 4 lines of Python. But, let us know if we can be helpful at all.
I think it’d make sense to build ontop of scrapbook eventually here. We’ll keep adding support for more edge cases in terms of visualizations and display manipulations that need to be handled as well as support for more tools that aggregate these scraps downstream.
What would help is input on the API or plugability you’d want to see there to make reuse easier. The intention is that the library is customizable to different usecases and made consistent for tools to access the results across those usecases.
Makes sense, and I agree. We went with this approach in the short term but intentionally used the same underlying metadata in the hopes that it doesn’t diverge from the patterns in scrapbook.
I think the API is nice - but in our case we only want the equivalent of display=True so it seemed like all of the extra machinery in scrapbook wasn’t necessary. And since Scrapbook also comes with dependencies on pandas, papermill, and pyarrow, those seemed heavy-enough that it wasn’t worth adding them when we could just replicate the functionality we needed with one four-line function