Track history of successfully loaded plugin versions

[MUFFANUJ]

Add a Plugin Load History feature that automatically snapshots the source of a plugin every time it is successfully loaded via "Load Current File As Extension". Users can browse past loads and restore a previous version into the editor. Have a configurable cap (default to some value per file) that evicts the oldest entry when exceeded.

[krassowski]

This sounds reasonable for a future enhancement. FYI jupyter-collaboration has a slider for going back in time (on the statusbar). We do not have it integrated with lite yet though, and the UX is not as good as named versions in say Google Doc.

It does make sense to have something dedicated for plugin playground because:

• it involves multiple files
• we could have a dedicated UI with a clear status that of whether the extension successfully compiled ✓ or not ✗

Some questions to explore:

• where could this go in the UI?
• could we integrate it with native checkpointing mechanisms and just add metadata to checkpoints?
  • does jupyterlite have checkpoints implemented in the first place?

[MUFFANUJ]

where could this go in the UI?

Some options can be:

• Another collapsible section in the existing sidebar tab.
• A completely new tab in the sidebar ( right )
• Or have a button in the toolbar, as this would be a file-specific feature. We could have a button on the panel ( bottom maybe ), and maybe having a panel would benefit in implementing Add diff view for plugin load history entries #140 ? might be overkill though

Maybe having a new/older sidebar tab with successfully compiled and not successfully compiled collapsible sections, and in each section, having a drop-down for each file with their older version, in each version having options to use this and check diff. Since the diff view is also planned, should we have a new tab in the sidebar?

[MUFFANUJ]

does jupyterlite have checkpoints implemented in the first place?

Yes, JupyterLite's Contents class fully implements checkpoints, storing up to 5 per file in IndexedDB via localForage. This is actually better than standard JupyterLab's default FileCheckpoints, which only keeps 1 per file on the server filesystem.

could we integrate it with native checkpointing mechanisms and just add metadata to checkpoints?

I explored this, and it partially works. We could call createCheckpoint() on every load attempt and store metadata (compile status, labels, etc.) separately in IStateDB keyed by checkpoint id. The cap is not a concern since we'd add one anyway.

However the fundamental blocker is the 1-checkpoint limit in standard JupyterLab(it's by convention). On non-Lite JupyterLab, FileCheckpoints only ever keeps 1 checkpoint per file by default; every new checkpoint overwrites the previous one. So the entire load history collapses to a single entry regardless of what we build on top, making the checkpoint layer useless as a storage backend.

JupyterLite gives us 5 slots, but since the plugin-playground runs on both environments, we can't rely on that. IStateDB gives consistent multi-entry history across both JupyterLab and JupyterLite with full control over the schema.

[krassowski]

Maybe having a new/older sidebar tab with successfully compiled and not successfully compiled collapsible sections, and in each section, having a drop-down for each file with their older version, in each version having options to use this and check diff. Since the diff view is also planned, should we have a new tab in the sidebar?

Another option would be to auto-version them via git and use tags to denote successful/unsuccessful executions. I am thinking about this because jupyterlab-git already provides a version history panel, and has support for displaying tags. We could automatically create new plugin files in new directories and auto-create repositories for them, and commit on auto-commit on each execution attempt (with an option to opt-out). The difficult thing would be the support of git support/persistence in JupyterLite context (or was it solved already?).

This also gives us diffing for free:

[MUFFANUJ]

The difficult thing would be the support of git support/persistence in JupyterLite context (or was it solved already?).

This problem is still persistent not solved yet for lite.

[MUFFANUJ]

The best behavior we can implement is a local-first history system: every successful Load Current File As Extension creates a snapshot in IStateDB (with per-file cap and oldest-entry eviction), and users can restore any past successful version instantly in both JupyterLite and Binder. In the future, GitHub can be optional sync, not the primary store: users can manually push selected snapshots and pull remote history when needed, with explicit repo/branch/path controls. Doing GitHub directly from the browser is feasible, but riskier because tokens are exposed to the browser runtime (and any XSS or compromised session can leak them). A GitHub-only design would also fail offline.

[MUFFANUJ]

The difficult thing would be the support of git support/persistence in JupyterLite context (or was it solved already?).

If this would have been solved, i feel this would have been a easier and better option.

[krassowski]

Maybe we could already add jupyterlab-git to Binder deployment and see if we can have an option to automatically create commits on execution attempt and add tags describing success/failure after execution. We could explore this workflow on Binder and if users find it useful, we can think how and when we could integrate it with Lite deployment. First thing would be checking if jupyterlab-git eposes commands/APIs to create tags/commits and what UI should we use to opt-in into this UX (I guess we should not do that on pre-existing repositories)

[krassowski]

Integration with Lite might become easier with jupyterlab/jupyterlab-git#1453.