add a visualise / view command about augur HOT 8 CLOSED

Thanks for the thoughts @stevenweaver.

I think this sort of script is definitely a helpful thing and I think it should exist. I don't fully know whether augur view (installed as part of augur module) or auspice (installed via npm install) is better. Though I'd learn toward the latter. There are a couple reasons.

1. I don't mind augur requiring something beyond what's installable as simple Python dependencies. We already rely on raxml, iqtree, mafft, etc... However, I really don't like enforcing the sister directory structure any more than we are already. augur is installed system-wide. This cuts against a call to augur view needing ../auspice/ to exist relative to the call point.

2. It would be nicer if rather than copying the files to the sister directory and calling npm run start:local if we provided a command like auspice --directory path/to/auspice/jsons that could then be run from wherever you currently are. I'm assuming this could be installed as part of npm install. This call to auspice would be what nextstrain view relies on.

from augur.

All valid points. Thanks for humoring me, and get in touch if you want a copy of the script I use for development.

from augur.

Hmm, this seems like an unnecessary coupling of augur with auspice and not a clean separation of concerns.

from augur.

• How is it different to calling ../fauna/... ?
• I would use this command all the time, but i'm happy to keep it as a personal shell script
• when it comes to the tutorial, this'd be nicer than saying cp data/auspice/*JSON ../auspice/data; cd ../auspice; npm run start:local;

from augur.

How is it different to calling ../fauna/... ?

The plan is that augur's not going to do that anymore though, right?.

when it comes to the tutorial, this'd be nicer than saying cp data/auspice/*JSON ../auspice/data; cd ../auspice; npm run start:local;

I think for a detailed tutorial using augur directly, your example actually provides greater insight. It's not like they haven't already had to use npm to install auspice deps, and if you want a high-level quick-start, then why not use nextstrain view? I think the responsibility for tying together the Nextstrain components into simple commands belongs outside of the components themselves.

If you just want to make the surface syntax nicer, then maybe auspice wants to grow a bin/auspice that wraps things appropriately into nicer commands than npm provides? This is akin to what the container image does and nextstrain view relies on.

from augur.

What do other people think?

I have a local script visualiseAugur which I use to do this, but if it'd be useful for other developers / users then I think it should become part of the repo.

from augur.

It's certainly not unheard of for a python package to have a visualization component. For example, there is snakeviz, an entire package dedicated to profiler viewership, and luigi comes with a web interface component. Those are just two packages that come to mind off the top of my head.

You could package auspice directly with augur by way of including a small tornado web application, and then include something like augur view as a script in the augur package that starts the web server and opens a browser.

The pro here is obvious, you would be able to view your results almost immediately and entirely within augur. The con is that it would complicate augur's build system (perhaps including webpack, yarn, etc. in the development instance of augur), and would include additional management overhead ensuring that the version of auspice used by augur is kept up to date.

I don't have an opinion on what is "right", but just sharing my past experience in trying to do the same thing a couple of years ago.

Maybe this is what the nextstrain cli command is already doing? I haven't looked at that yet.

Best,
Steven

from augur.

However, I really don't like enforcing the sister directory structure any more than we are already. augur is installed system-wide. This cuts against a call to augur view needing ../auspice/ to exist relative to the call point.

To be clear, in the scenario described last night, augur would have its own instance of auspice installed within the package. I would not recommend dependence on a directory installed outside of the package unless during development. During development and under the first scenario, using yarn link would be used to develop in auspice and augur in tandem.

With that said, I lean towards the latter as well, especially since auspice already has high visibility as its own package. In our case with our own projects, we would still want to try to install the npm package, or make it very clear that you may need it in some way, from the primary python package.

Best,
Steven

Edit :
A caveat with the second approach is that the version of augur with which the results JSON was generated would need to be inspected by auspice for compatibility. A change to the JSON schema may result in breaking changes unbeknownst to auspice, and version mismatching will be inevitable as researchers archive their results over time.

from augur.