Join GitHub today
GitHub is home to over 36 million developers working together to host and review code, manage projects, and build software together.Sign up
Run workflow form revision #2077
In order to reliably replicate the behavior of the current run workflow form, this PR contains a minimal, controller-consistent workflow api endpoint. It would be fine to remove this endpoint within this PR and redirect the client, once we understand why currently existing api endpoints and legacy variations are unable to replicate the basic behavior expressed by the current workflow controller endpoint. I think that the presented endpoint can assist to understand the differences.
Please set the galaxy.ini flag
7 times, most recently
Apr 4, 2016
referenced this pull request
Apr 5, 2016
Thanks for the detailed response. Yes, please fix the invocation endpoint to accept these and add any other regressed feature to existing API endpoints such that they are consistent with the existing controller endpoint e.g. thanks for adopting the missing linked and unlinked batch mode features which were re-implemented in this PR by merging #2464. Without this feature users would have not been able to use any batch mode options with the new run workflow form. Correct me if I am wrong, but I noticed another feature which is not supported by existing API endpoints but by the endpoint presented here which is that data input modules should be able to submit multiple selections if associated with a multiple input data parameter. Now, the new API endpoint, which is the focus of this discussion and which is blocking the introduction of the new run workflow form, contains only about 50 lines.
I'm a strong
Jul 7, 2016
4 checks passed
@guerler I've chatted with a few people about this and been thinking about it myself - I have gotten the sense that perhaps you were just eager to get this done with so you can move on the tool form work? I'm not eager to take up the UI work needed to do this well - but if you are eager to just move on I'd rather do the work myself (or with the help of @martenson) than let this PR into a Galaxy release in this form.
If over the next few months, I take over the form work you started would you be willing to revert this PR? Would this free you up to work on something you feel more passionate about - such as viz?
I don't want to speak for @guerler here, but it looks like he's tried to make this work with existing endpoints for quite some time before going this route. In my opinion backing it out of the release isn't necessary if this serves a useful (if temporary, as specified in the PR summary) stepping stone for his work on the workflow editor.
Would adding words of warning to the endpoint documentation stating that it's not expected to be a permanent API addition, etc, be a reasonable compromise?
Or, perhaps change the route name as well?
There's a precedent for this sort of work being in releases in the history contents API and the handling of the 'dev' key, which swaps to index_v2, below, with different options and behavior. https://github.com/galaxyproject/galaxy/blob/dev/lib/galaxy/webapps/galaxy/api/history_contents.py#L470
The issue is not really UI related, the problem is that the
@guerler I agree the UI is not the challenge here and I also support @jxtx with moving the new (temporary) endpoint to something like
There is no "regression' in the workflow invocation API - I don't like this framing and I don't think it is at all appropriate. The invocations endpoint was initially designed to replace the old workflow run API - and it is feature complete with respect to that - or at least the portion of that which has tests and which I understand. The act of replacing the workflow run form to target the API instead of a controller method is work undertook by @guerler and I guess is the scope of this PR. I don't think it is at all fair to claim I "skipped existing features to be fixed by others" - it is work I'd be willing to do, eager at this point, but we are going to ahead with a new API endpoint instead of continuing work on the existing API endpoint.
As for the 3 "regressions":
@jmchilton Do you object to the compromise of having the workflow UI use a non-public non-API endpoint for the next release, and then working on changing the client / API / both to come up with a better solution in the next release? This lets us make some incremental progress while we reconcile the work you've done on creating an improved workflow invocation endpoint with the additional capabilities the workflow client UI needs (but, as you point out, were never part of the invocation API).