You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Although this would introduce some extra complexity, it is (I think) a current requirement of Jupinx.
Once #10 is implemented it would be possible to 'orchestrate' consecutive notebook execution, whereby:
A notebook is executed and its final state and artefacts committed.
A subsequent notebook is staged for execution with (1)'s nbfile and/or artefacts as it's assets.
That notebook is executed
The orchestration could possibly be done at the staging phase, from a top-level; stating which notebook relied on which, or from the notebook-level; stating a relative path dependency in the metadata (this may be less robust). Then the cache or executor would work out a 'branching tree' of execution paths (checking it is acyclic) and decide how to execute appropriately.
The artefacts from the first notebook could be either/or files that the notebook outputs or its final kernel state (using something like dill.dump_session)
The text was updated successfully, but these errors were encountered:
Although this would introduce some extra complexity, it is (I think) a current requirement of Jupinx.
Once #10 is implemented it would be possible to 'orchestrate' consecutive notebook execution, whereby:
The orchestration could possibly be done at the staging phase, from a top-level; stating which notebook relied on which, or from the notebook-level; stating a relative path dependency in the metadata (this may be less robust). Then the cache or executor would work out a 'branching tree' of execution paths (checking it is acyclic) and decide how to execute appropriately.
The artefacts from the first notebook could be either/or files that the notebook outputs or its final kernel state (using something like dill.dump_session)
The text was updated successfully, but these errors were encountered: