-
Notifications
You must be signed in to change notification settings - Fork 114
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
Remove custom tool state handling #207
Conversation
I'm fine with breaking backward compatibility I think as long as we are moving toward a more simple over the wire format. Like anywhere we have strings encoding json in json objects - that is real bummer. Am I reading this correctly that the recent Galaxy PR made something that was a string encoding JSON into just a JSON object directly? Do you have before and after examples of what was going over the wire? |
Not yet, but the Galaxy PR allows us to do exactly that now that the state handling has been unified. Here is how we can store all workflow step states as json-dictionaries without stringifications while still be able to load previously stored workflow steps: https://github.com/galaxyproject/galaxy/compare/dev...guerler:store_step_states_as_dict?expand=1. I did not want to change the tool state generation process in the previous PR. Historically, we started of with a hash-encoded string of nested-json strings and moved to a regular string containing nested-json strings, now we can transform this as shown in the branch above into a regular dict-object. Either way the custom json.load of the first-layer happening in bioblend is not an option. |
I like https://github.com/galaxyproject/galaxy/compare/dev...guerler:store_step_states_as_dict?expand=1 I think - it seems like a good step forward at first glance. I still don't have a grasp on where these things are coming from and going to - what things look like over the wire - etc.... I have to just trust you I think or spend an afternoon figuring this out. The fact that this change doesn't break older Galaxy releases means the encoding loads was probably always redundant? +1 I guess. |
This is the difference when executing:
for a very simple workflow.
Galaxy dev:
|
Thx @nsoranzo. I am working on providing the dict for the tool state directly through Galaxy (see: galaxyproject/galaxy#3522). Its still a work in progress but if that turns out to be more difficult I will leave the existing customization in. |
Great, makes sense. Thanks. |
Tests, including the new ones @nsoranzo added, pass locally, I think the failing test is not related to the change here. |
@nsoranzo Are you okay with this being merged now? |
Unfortunately that's going to break the experience for Galaxy <= release_17.01 (where the values in the @@ -170,7 +170,13 @@ class Step(Wrapper):
raise ValueError('Unknown step type: %r' % stype)
if self.type == 'tool' and self.tool_inputs:
for k, v in six.iteritems(self.tool_inputs):
- self.tool_inputs[k] = json.loads(v)
+ # In Galaxy before release_17.05, v is a JSON-encoded string
+ if not isinstance(v, six.string_types):
+ break
+ try:
+ self.tool_inputs[k] = json.loads(v)
+ except ValueError:
+ break
@property
def gi_module(self): Any objection if I commit this instead? |
Superseded by commit 0be30ac . |
The json.loads here is strange for nested parameters like repeats, sections and conditionals, properly decoding the parameters would be the right thing to do. Alternatively I can make consistent adjustments such as loading or decoding the states dictionary on the side of Galaxy. The location at which all Step input states are stored is here: https://github.com/galaxyproject/galaxy/blob/dev/lib/galaxy/workflow/modules.py#L72. I believe that we have quite some flexibility in the storing format at this point and it would be great to talk about what the preferred format is. ping @jmchilton