Add visualization plugin for .qzv files

[ebolyen]

Addition Description
There needs to be a way to view .qzv files inside Galaxy. It isn't yet clear how to dynamically serve files as each .qzv file is essentially a mini website with static assets and an index.html file.

Questions

1. Should a visualization plugin be used for this? Or should it be a display application to q2view? The latter won't work with non-TLS endpoints.

References

1. https://galaxyproject.org/develop/visualizations/

cc @blankenberg, any ideas here?

[blankenberg]

There are few potential ways to handle this.

1. Quickest, by far, is to just send the user over to e.g. https://view.qiime2.org/ with a GET parameter that contains a URL that has the .qzv/.qza file. The main gotchas here are the TLS concern that you mention, the inability to use it if Galaxy is behind a firewall (could have a local q2view installation inside the firewall though). Do we need to worry about CORS being set, or does q2view use a retrieval method that doesn't care?
2. If the .qzv file can be easily transformed/exploded into an actual static index.html file and assets, that would be viewable if you just dropped it in an e.g. web server directory, then we could also add a tool that creates an output of type html, with the index.html file as the main dataset, and the additional assets put in the extra_files_path for that dataset. The user could then click on the eye icon to view the visualization. If a command for doing this already exists, e.g. just unzip followed by a cp or mv would give us the visualization tab, but not the provenance tab, etc. It would also require a separate tool run, but avoid TLS and firewall concerns. This is second quickest/ second least effort.
3. Otherwise, a visualization plugin can be made, but this tends to be a bit more work and things are more likely to diverge from the best-practice view (i'm assuming q2view). When done well, however, they do work really nicely, and avoid the problems if Galaxy is not under TLS and will also work if the Galaxy instance is behind a firewall. Unfortunately, these aren't yet supported for install through the toolshed, so each 'plugin' actually needs to be added to the main codebase for it to be usable by most people at this time.

I just checked the reference you provided, which is actually a good summary of everything I just typed out here, so I'll provide my two cents:
Option 1. from above is probably the best bang for the buck at this time -- this reply took longer than I would have taken to add the external display application. If the visualizations were actually installable from e.g. the toolset, then I'd give more weight to option 3., otherwise there might be some licensing mismatch concerns, depending upon what e.g. JavaScript would need to be added to Galaxy (copied from q2view into the Galaxy codebase? I did not check the license).

[blankenberg]

xref ebolyen/galaxy#1

[ebolyen]

Thanks so much for the detailed explanation and the PR!

I'll test out that PR shortly, but will requiring CORS+TLS be a realistic issue? How common is it to have a galaxy deployment on localhost?

I do really like 3 as a long-term goal, one of the things we keep saying we'll do is pull out the provenance DAG as an NPM installable component so that we can share it between interfaces. This would be yet another reason to do so.

As for 2, that may actually be easiest, as all we need to do is serve a directory at some path. Would this require the user to run a second tool, or can a tool run execute as part of the "inspect-eye" button? It kind of sounds like the extra_files_path is for managing datasets of multiple files, so would we be doing a transformation from .qzv -> index.html + extra_files as a new dataset? If so, could this be made transparent to the user?