[Feature/Documentation Request]: Workflow -> Python Script option? #1341
The ability to convert a widget/gui workflow directly to an equivalent Python Script file. Even if it's ugly.
As it seems right now, Orange supports either the GUI workflows OR directly using/writing python scripts that access the orange data-mining suite.
OR... if this is possible... it doesn't seem to be documented clearly anywhere that I could find.
Steps to reproduce the behavior
Additional info (worksheets, data, screenshots, ...)
I'm an instructor at a university, and teach some of our data mining and introduction to data science courses. I've used Weka before, but rather dislike it's interface and mechanisms. I also usually teach R as part of the data-mining, but would really like something with a much lower learning curve as an introductory software piece. Possibly to avoid even some of the initial issue of actually teaching PROGRAMMING instead of the bigger data-science picture.
Orange almost perfectly fits that bill with the GUI and being able to actually write python scripts directly to do the data-mining. HOWEVER.... there's a huge downside of needing to write it a 2nd time once you've figured out the work-flow AND of correctly using the python back-end.
Ideally, I'd love the option to turn on a 2nd "window" (or at least a widget or save option) that shows the equivalent python script calling the Orange mining procedures. I think this might also be very useful for actual USERS of Orange, as it would let them design a workflow at a high-level of abstraction and editing, then output to a python script. This would allow minor tweaking directly in the code or work to merge/enhance things outside of options available in a given widget.
The text was updated successfully, but these errors were encountered:
So... if this is something you've got penciled in/outlined...
I've got a summer research student of my own who's familiar with Python. I
As I said in the issue... that's partly selfish interest as I'd love to use
Hi, I'm the research student assigned to work on this task. I just wanted to show my current progress and make myself open to input and suggestions. However, after some initial review by @kernc, it seems that what I have done so far isn't quite in line with the overall vision for this project so it's likely that most or all of the code generation will have to be re-written to meet the new model.
Current progress: https://github.com/Ameobea/orange3/commits/script-export-gui
The first thing I did was create a topological sort function for the workflow DAG which created a sorted list of nodes to be processed in order so that all dependency nodes are processed before their children. The nodes are then converted into a widgets. Each widget's
The code generator consists of multiple parts including generating import statements for required modules, generating declarations that go inside
The goal of the generator is to insert all necessary code from the widget into the output to perform the same function as the initial widget without modifying or re-writing already existing widget code. I went out of my way to avoid modifying any existing widget code or so much as copy and paste a line. However, it would certainly be much more efficient in terms of the size of the output code and simplicity of the generation process to do that.
Note: This is in response to a separate email where Kernc provided some sample "ideal" code.
So, looking at the two files that Kernc produced and you (Casey) produced, I partially agree with Kernc, but perhaps can point to the what (might) be the actual issue...
Kernc is using the orange data mining library in his script as if it was actually a python script written with the mining library initially.
What you almost need is a 2nd "wrapper" around what you've generated that actually makes the final python lines or code.
Basically, your (as generated now) code would create a single "output string" from _describe --> that actual output string gets entered into the final python script/code either as a displayed line or comment.
Then, based on the full parsing of the 'init' , '_get_reader' and 'get_output' functions, generate 1-2 lines similar to Kernc's lines for file-loading that is correctly calling the actual mining library's read/load files.
You might also just be over-thinking what sorts of information you need from the actual widgets --> library use.
The orange documentation though doesn't do a great job of discussing the ability to load from a URL vs. a file-path...
Remember that while the widget makes the gui pretty and easy to use, theoretically at least as much functionality (including error catches) should be built into the library itself.
Basically, your "code generator" from the canvas needs to get the attributes from the widget with the file or url path, and then call the appropriate table function with the path. So you can hide the "decision" in your code generator, and then generate the simple 1-2 line code for loading the table.
orange.data.table already contains all the needed imports and checking of the filenames etc. I don't know if it does the helpful output of how many of what attributes the data has, but those ought to be otherwise-callable if needed.
I think part of your challenge here may be that, unlike I initially thought, it looks like the widgets (or at least this file widget) doesn't actually call the mining-library functions via wrappers.
@Ameobea was working on it.. (he is/was an undergraduate student working under me). I don't believe he ever finished the capability, due to some dependencies elsewhere.... I can check in with him about it though. I think some of what he had working was really just an ugly use of the same widget structure, rather than actual native python/orange calls....and wasn't quite as pretty as we'd all hoped might happen. ================================================== To schedule a meeting or appointment try: https://karlrbschmitt.youcanbook.me/ Dr. Karl Schmitt Assistant Professor Department of Mathematics and Statistics Department of Computing and Information Sciences Director of Data Science Program Director of Analytics and Modeling Graduate Program Valparaiso University, Indiana ==================================================…
On Mon, Aug 20, 2018 at 6:39 PM, Joseph Bennett ***@***.***> wrote: I think @Ameobea <https://github.com/Ameobea> worked on the request for a while, but it is not as easy as one might hope. More Details: Ameobea#7 <Ameobea#7> https://ameo.link/u/bin/2jb https://paste.debian.net/779226/ Having deployment functionality like this would make Orange a superior top tier development tool. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#1341 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AMRGU-HPSmikI2Zl3oWxsSRCT18_fGygks5uS0itgaJpZM4I2y2Q> .
Actually I was developing my own software for machine learning GUI (Link) but then i found orange on intenet which is a peace of art i would say. But I can help to make python script converter. Please help me if you have any starting point from where should I start.
As a part of the regular issue purging fest, I'm closing this one. I don't think that implementation of this feature depends upon whether this github issue is here or not.
To support conversion of workflows into scripts, each and every widget would have to provide the necessary code (or whatever definitions that would be required). Otherwise, a workflow would be convertible only if it contained only convertible widgets. Hence, users would constantly complain about each and every widget that does not support this functionality. Besides, whenever a widget is improved, the improvements would have to be reflected in the exportable code. This would put a lot of burden on widget developers.
There may come time when the core group decides that Orange absolutely needs this feature and it's worth investing time and promising the future commitment. If this happens, we are going to implement this feature - and having this github issue open or not does not affect this decision.
Having just a subset of widgets with exportable code would be tremendous. Or even having an example of code equivalent for each widget might be used would be of great value. Orange is so useful for exploration and analysis, but a script may be more useful for deployment.