search

laminlabs / laminr

R client for LaminDB.
http://laminr.lamin.ai/
Apache License 2.0
8 stars 1 forks source link

🚸 Alerting interactive notebook users for a version bump in case a notebook was already saved #122

Open falexwolf opened 3 days ago

falexwolf commented 3 days ago

After saving it, somebody keeps a notebook file around locally, the hash doesn't change and hence there is no alert for a version bump, and they re-run it and then make live edits while running it. Only once they hit db$finish(), they'll get a warning that their source code changed compared to the saved version. This is annoyingly late.

We're not running into this situation with .ipynb workflows because we're requiring a version-bump whenever somebody runs ln.track("...") on an already-saved notebook in an interactive Python session. We could do the same with .Rmd and .qmd but then we'd always require version bumps even if the notebook is re-executed non-interactively. This isn't acceptable, of course.

The only way of dealing with this case, is, I think, to determine whether an R session is interactive vs. non-interactive (the equivalent of an ipython vs. a python session). We could then require the version bump for an interactive session as we do for ipython.

lazappi commented 16 hours ago

I think it should be fairly easy to detect if db$track() is being run interactively but maybe harder to tell if it is in an interactive "notebook" vs a .Rmd/.qmd that is supposed to be rendered non-interactively. I'm not sure how running a chunk in an auto-knit notebook should be detected and handled compared to run the same chunk in a document that needs to be rendered to produce a HTML output.