Address removal of `augur export v1` for private.nextflu.org builds

[joverlee521]

Context

augur export v1 will be removed soon, but we still use it in the private.nextflu.org build.

Possible solutions

Short term

We can pin the docker image used in the private nextflu workflow to a docker-base image that still has a version of Augur that has augur export v1.

We cannot do this indefinitely because the private nextflu workflow is built on top of the core workflow. If we make backwards-incompatible changes the in the core workflow (e.g. use the new refine --remove-outgroup flag) that are not available in the pinned version of Augur, then the workflow will fail. (Edit: I guess we could pin the private nextflu workflow to a commit to work around this, but that will prevent us from updating the source files like reference strains. Sounds like a bad set up!)

Medium term

Keep augur export v1 as a custom script in this repo to continue using it in the workflow.

Long term

Sunset private.nextflu.org

[jameshadfield]

Keep augur export v1 as a custom script in this repo to continue using it in the workflow.

I think this would be minimal work - export_v1.py imports a dozen or so augur functions / classes but I think the API is stable on all of them. I think read_config will go away with some of the work I have in store, but that's easy to copy-paste into export_v1.py itself. There's also not a urgent need to get nextstrain/augur#1754 merged if it makes your life easier to hold off for a while.

[joverlee521]

I think this would be minimal work - export_v1.py imports a dozen or so augur functions / classes but I think the API is stable on all of them. I think read_config will go away with some of the work I have in store, but that's easy to copy-paste into export_v1.py itself.

Good to know! I haven't dug into the specific imports, so I wasn't sure how much we would need to copy over.

There's also not a urgent need to get nextstrain/augur#1754 merged if it makes your life easier to hold off for a while.

I've already blocked this work before...clearly it won't get prioritized unless we set a deadline 😅 Not sure we want to wait on long term solution of removing the private site, so happy to go with the medium term solution of vendoring export_v1.py.

[victorlin]

Echoing James – I don't see a need to remove export v1 any time soon. The deprecation rather than removal itself was the most important part of nextstrain/augur#1266, to get the point across that we aren't maintaining this anymore and to discourage others from using it. I think if this ends up requiring more than a simple copy/paste of export_v1.py, we can defer the removal.