Michael Goerz

Closing in favor of https://github.com/JuliaRegistries/General/pull/106167

I'm seeing the exact same bug as described in https://github.com/mwouts/jupytext/issues/1124#issuecomment-1723280296 (paired with the "light" script). The `jupytext` and `jupyter-collaboration` appear to be mutually incompatible. I've opened https://github.com/jupyterlab/jupyter-collaboration/issues/214

The issue is still there with the newest jupyter-collaboration 2.0 release: https://github.com/jupyterlab/jupyter-collaboration/issues/214#issuecomment-1858353452

[noblock] LGTM, but of course, you have to fix the issues flagged by the bot. When you do, just repeat the registration comment, and the bot will automatically update this...

[noblock] There's no rush! It's entirely up to you. The bot will merge automatically after the issues have been fixed and the three-day waiting period has elapsed. You'll also have...

[noblock] [Your comment](https://github.com/JuliaRegistries/General/pull/105728#issuecomment-2081085781) is blocking the merge, so you have to edit it to contain `[noblock]`

Thank you for submitting your package! However, please extend the README a bit more before the registration can be merged. [At the very least](https://discourse.julialang.org/t/when-does-it-make-sense-to-post-a-new-package-to-the-julia-repository/108701/4), it should include a small usage...

> I can usually pull these quantities out of the original state Well, I thought I could, but it turns out the `state` is woefully inadequate, at least for some...

[noblock] I have no particular opinions here, although I agree that `AllocArrays` and `MallocArrays` seem a little too close for comfort. Maybe get some more eyeballs on this on Slack...

That would be great, at least when that makes the version ambiguous, as in `1.10 -> "1.1"`, see https://github.com/JuliaDocs/Documenter.jl/issues/2474