Difference between revisions of "API Design"
Jump to navigation
Jump to search
(Created page with '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? **…') |
|||
(10 intermediate revisions by 2 users not shown) | |||
Line 9: | Line 9: | ||
*** In a script we only need to call modules. Is there other things we would like to do? | *** 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. | *** We could also have a more integrated version of scripts where provenance is recorded? But this would require more control of the python script. | ||
* [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? | |||
* [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 | |||
* [RR] | |||
** 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]) | |||
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.