Difference between revisions of "API Design"
Jump to navigation
Jump to search
| (3 intermediate revisions by the same user not shown) | |||
| Line 31: | Line 31: | ||
** Example target: [http://nbviewer.ipython.org/gist/remram44/a59a6dbf2026a0433ede notebook]<br> | ** Example target: [http://nbviewer.ipython.org/gist/remram44/a59a6dbf2026a0433ede notebook]<br> | ||
** Right now: [http://nbviewer.ipython.org/gist/remram44/9454edf54d58909ee69b core api], [http://nbviewer.ipython.org/gist/remram44/242bd94bd298057ff750 with gui] (disregard [8]) | ** Right now: [http://nbviewer.ipython.org/gist/remram44/9454edf54d58909ee69b core api], [http://nbviewer.ipython.org/gist/remram44/242bd94bd298057ff750 with gui] (disregard [8]) | ||
Problems: | |||
* [https://www.vistrails.org/ticket/660#comment:1 Sort out 'mode' options] | |||
* ([https://www.vistrails.org/ticket/840 #840 IPython integration]) | |||
* [https://www.vistrails.org/ticket/884 #884 Enabled packages in configuration shouldn't affect API or batch-mode] | |||
* [https://www.vistrails.org/ticket/886 #886 Sometimes the controller's change_selected_version() needs from_root=True from unknown reasons] | |||
* [https://www.vistrails.org/ticket/892 #892 Log propagation in vistrails] | |||
Work in progress on branch <tt>new-api</tt>. [http://nbviewer.ipython.org/gist/remram44/2a67e6269ba2f052a19d Notebook]. | |||
Latest revision as of 17:22, 6 August 2014
This page is for discussing changes to the vistrails API. Specifically to make it easier to use with scripting.
- Create layered API with interactive API on top of scripting?
- [TE]
- I don't see how this would work. For scripts, the way we are currently thinking about them, would not interface strongly with vistrails. What we currently have is a vistrail api. For scripting, I would like to have just a module API with an executeModule method that:
- Sets parameters and inputs
- Creates and executes a vistrails module
- Makes outputs available
- In a script we only need to call modules. Is there other things we would like to do?
- We could also have a more integrated version of scripts where provenance is recorded? But this would require more control of the python script.
- I don't see how this would work. For scripts, the way we are currently thinking about them, would not interface strongly with vistrails. What we currently have is a vistrail api. For scripting, I would like to have just a module API with an executeModule method that:
- [TE]
- [RR]
- API for embedding/extending/controlling VisTrails
- Would be used by other tools like DAT, and packages like the spreadsheet which interact strongly with VisTrails
- Would probably resemble what we currently have
- Can be a bit more involved (and unstable?)
- "library" API, used in scripts to create/load/run pipelines or vistrails (+ IPython magics)
- API for generated scripts, used to run modules that couldn't be translated
- This is what I get from TE's description above
- Why do we need this?
- API for embedding/extending/controlling VisTrails
- [DK]
- Agree with RR that the general VT API focus should be used for embedding/extending/controlling VisTrails
- The current API combines some stateful commands (new_vistrail/execute_workflow) with the script-based workflow construction
- We need to improve this; I think there is too much that has to be done with the controller right now.
- WRT the module scripting API TE proposes, I think this is mostly orthogonal
- I see TE's point that running a module outside of the workflow structure is not straightforward right now
- This could be another focus and would be specifically for the scripting work
Problems:
- Sort out 'mode' options
- (#840 IPython integration)
- #884 Enabled packages in configuration shouldn't affect API or batch-mode
- #886 Sometimes the controller's change_selected_version() needs from_root=True from unknown reasons
- #892 Log propagation in vistrails
Work in progress on branch new-api. Notebook.