Galaxy Tool IDE

[hexylena]

I'm tired of:

• trying to figure out what parameters are and aren't available due to the lack of documentation on Tool XML Syntax. E.g. figuring out how to access things in dataset_#_files/ took a dozen tool runs/reloads + grepping through the source for the parameter.
• the context switching involved in writing Tool XML:
  1. write tool with bugs
  2. refresh Galaxy/reload the tool (helped with the auto reloader... but that's not fun to configure sometimes)
  3. run the tool, see that it fails
  4. try and figure out where your XML went wrong, back to i.

I'd like to see a CodePen/JSFiddle for Tool XML:

I want:

• one pane for editing the tool XML which is reloaded live/constantly into
• a second pane for viewing the tool form and filling it out interactively, which is then reflected in
• the command line pane at the top right showing the complete command line (in copy-pasteable form)
• and any other associated files like <configfiles/> blocks at the bottom right

[nturaga]

@erasche Totally agree with this.

[jmchilton]

This would be cool, but your workflow could be better even without it - for 95% of tools you should never load the tool in the UI until it it is done - test driven development.

[hexylena]

@jmchilton I find TDD lacking in Galaxy tools when:

• there isn't complete documentation of parameters and exploration is required. Having that be interactive makes it an order of magnitude more pleasant, especially for new tool devs.
• tests take some non-trivial amount of time to run and you JUST need to see what the command line looks like / how your configfiles are being rendered. My JBrowse tool has hundreds of lines of <configfiles /> which have been painful to generate due to the lack of interactivity. Under TDD I'd have to:
  • apply the planemo parameters to not-delete files
  • lint/debug those configfiles to see that e.g., "oh, I need to str(param) == "None" to get that working like I expect"
  • (optional) clean up those files
• lack of nice syntax / lack of documentation on the nice syntax available for writing tests against dataset collections.
• multiply nested macros. When you have to manually search through 2+ levels of macros to figure out the name a specific variable will be available under, I don't reach for TDD, I would rather reach for Galaxy which can calculate the name of that parameter in a second.

Edit: maybe I just find myself working on 5% tools, 95% of the time? And the 95% tools take 5% of the time to write because of trivial options/test syntax?

Update 2015-12-28

Editing the comment rather than posting a new one in order to not make noise about a feature others clearly aren't as desiring of as I am.

Had another moment today where I wrote a bunch of

echo 
#for x in dir($input_var):
  $x
#end for

because .files_path isn't an attribute on inputs, only on outputs. Instead you have to dig through the hiearchy, knowing what you're doing, to find $input.dataset.files_path.

Would have been easier and required fewer (edit tool xml, reload tool, run tool, inspect command line) cycles to determine what the correct attribute name was with a tool dev studio.

[bernt-matthias]

I guess this is solved by the galaxy language server?

[hexylena]

It isn't yet. It will be by galaxyproject/galaxy-language-server#124 (and maybe the configfiles/cli rendering as well, since that's a pain point for me)