-
-
Notifications
You must be signed in to change notification settings - Fork 1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Improve portability of Orange3 workspaces by using relative instead of fixed file paths #4464
Comments
Relative to what? |
Relatively to the location of the workspace (.ows) file. |
I don't like the an-option-to-store-relative-paths part. I assume this would be a checkbox that many would not understand, and we'd like to avoid such things if possible. Computer scientists understand the concept of "relative path", while most lay people don't. Always saving relative paths would be a bad idea, too, because the file can be completely elsewhere, and moving the workflow file shouldn't affect the file's path in this case. Currently, the File and Distance File widgets stores absolute paths, but resolves them later by searching for the file in "possible relative paths". If you, for instance, save the workflow in the same directory as the file, or if the file is in a subdirectory of the directory with the workflow's file, re-loading files should work. The Load Model widget doesn't do it, but it should. For widget that save files (Save, Save Model, Save Distance Matrix...), we don't have a useful mechanism, and I don't think we should change this. I suppose it's OK that saving requires user's action. |
Well, my usage scenario for Orange is to use it for teaching the basics of machine learning already early in school, starting around 7th grade. For this, I am currently developing a "playful" machine learning scenario. The informatics and/or mathematics teachers I am going to interact with (while discussing how to integrate the machine learning part into their regular school curriculums) are not data scientists. They may have decent IT knowledge, but I still think that it would be beneficial to spare them of any non-necessary manual modifications to a pre-provided Orange Workspace, such as having to modify all Load and Save widgets in the Workflow before being able to use it. My Orange workspace makes much use of Load-CSV and Save-CSV and Save-Model widgets. I didn't know that the vanilla "File" widget is doing a "possible relative path" search. |
I work with schoolchildren, too, so I can understand your frustration when you have to make extra steps that are unrelated with what you actually want to teach. I was mistaken thinking that this is technically difficult to do for widgets that save data. At today's core team meeting, @ales-erjavec explained to me how this is actually done in File and Distance File widget, and unless I'm mistaken again, this should be easy to do for all widgets. We'll do it. |
Awesome! Count me in as beta tester. :) |
@c-a-schiller, time to start beta testing if you want. :) |
I would like to, but I am total newbie in this (sorry) --> how can I get the new test build with the new feature? |
Is your feature request related to a problem? Please describe.
Orange3 workspaces are not portable because the widgets with load/save functions use fixed/hardcoded file paths. That means if a workspace is moved from one machine to another, all load/save widgets have to be touched again manually, and parameters of load/save widgets have to be set again, which is very cumbersome and time-consuming.
Describe the solution you'd like
If all widgets with load/save file functions had an option to store relative paths instead of fixed/hardcoded ones, workspaces would be much more easy to port from machine to machine.
Describe alternatives you've considered
I don't see an alternative to my proposed solution right now, except the above-mentioned manual process, which is very slow, cumbersome and error-prone (due to the fact that widget parameters get lost when re-linking to a new file on the new machine.
Additional context
n/a
The text was updated successfully, but these errors were encountered: