search

emmahodcroft / hello-world

GitHub tutorial
0 stars 0 forks source link

Tick List for `v6` #4

Open emmahodcroft opened 5 years ago

emmahodcroft commented 5 years ago

  1. GFF annotations a. minor augur changes, mostly done by Richard b. minor auspice changes

  2. Separate branch/node attributes a. probably LOTS of work in augur & auspice b. Is it worth it? What about internal (?) JSONs?? Need to look at this more closely

  3. BibTex a. Minor augur & auspice changes

  4. Add hidden attribute parsing to augur export a. EASY

  5. augur export config composition a. What overrides what? What's minimum required? (EBH) b. Tweak/confirm command line config flags/args

  6. Schema works for multi-color-bys?!? (#184)

  7. Run all datasets on AWS and test extensively

  8. Merge BEAST branch

  9. Change color-by schema from {} -> [] (dict to list)

  10. Should all meta-keys be under a 'meta' key in JSON? (#183)

  11. Bug #299 - True/False traits

  12. export v2 questions from Emma: a. What is intended function of URL field? Seems confused. (see auspice #734) b. How should we generate keys? Need to know URL uniqueness for this. What would be most robust? c. Make export spit out less errors and warnings - totally overwhelming ATM. Related to a) and b) above d. How does tip-frequency data integrate into new export v2 JSON - still separate? Integrated? e. Do we support default view in export v2? Are all aspects implemented? f. How does panel specification work? What will show by default? When will excluding one def. exclude it? g. Do we need --tree-name? In what circumstances? h. Do we support --output-sequence --reference --reference-translations yet? If not, can we comment these out for the time being?

  13. Add export/augur/JSON version explicitly to export JSONs (EBH)

  14. Fix weird --title quote requirements in export v2 (EBH)

emmahodcroft commented 5 years ago

I hadn't looked at #6 above / issue 184 previously (multi-color-by suggestion). I certainly was thinking multicolorby was something we could tackle after v6, but hadn't thought it might have JSON format changes that meant we should maybe think about it now...

I'll try to look again - I see the advantage of not having a bunch of stuff messing up the colorby dropdown, but it seems to me like you may not necessarily know ahead of time what combinations of things you would like to color by. For me, they would often be exactly the same things as what I colorby now, just two together (host and lineage, genotype and symptom) - so I'd want to be able to have them both ways. Hmm.

jameshadfield commented 5 years ago

I see the advantage of not having a bunch of stuff messing up the colorby dropdown, but it seems to me like you may not necessarily know ahead of time what combinations of things you would like to color by. For me, they would often be exactly the same things as what I colorby now, just two together (host and lineage, genotype and symptom) - so I'd want to be able to have them both ways. Hmm.

The main use case which prompted this (so far) was a panel of drug susceptibility MICs where you may not want those 20 appearing individually in the dropdown, but do want to see them all side-by-side. If we sort out the syntax and it's a simple extension of the 2.0 schema then we can add it in later, or include it now with the comment that auspice doesn't yet support it 😉

emmahodcroft commented 5 years ago

Yes, and definitely I have datasets where this would be good for me in the same way! So maybe I'll rephrase:

Will it be possible to support both datasets that we only want to color-by via multi-colour-panel (MIC scores) and 'DIY' multi-colour-panel of regular 'drop-down' color-by options (ex: country and host)?

For the first, let's say you recognise ahead of time that you don't want to colour by these individually, so you can 'tag' them somehow so that they go in as a particular syntax that means they won't show up as normal color-by. But for the second, you may not recognise before a run that you want to multi-colour-by them, and also you'd want them to be in the normal color-by drop-down - so could you make a multi-colour-by 'on the fly' from any existing drop-down options?

Could we support both of these? I think so, just takes some thinking. Would also mean (possibly)? That if we set up now for the MIC version (something like what Trevor proposed), we don't have to implement this yet (if we want to prioritise getting v6 out), and can draw from existing color-by schema/syntax to do DIY-color-by, without having to think about it now (as far as JSON changes).

emmahodcroft commented 5 years ago

I'll try to answer a few of my questions in my 'moving to v2' guide, but let me know when would be good to chat about config files for v2 sometime :)

jameshadfield commented 5 years ago

could you make a multi-colour-by 'on the fly' from any existing drop-down options?

💯 -- but this is an auspice issue to be solved (post v2 release)

we don't have to implement this yet (if we want to prioritise getting v6 out), and can draw from existing color-by schema/syntax to do DIY-color-by, without having to think about it now (as far as JSON changes).

Sensible I think. As long as JSON changes are additive & don't break anything they can be added in later to v2 (v2 JSON & v2 auspice)

jameshadfield commented 5 years ago

@emmahodcroft the current augur v6 branch now has a test runner which runs all the build tests & copies them into a folder so they can all be viewed in auspice, which is super convenient for developing branches 🎉 

bash tests/builds/runner.sh
auspice develop --datasetDir tests/builds/auspice
image
emmahodcroft commented 5 years ago

Updated to-do list: (Please feel free to edit further - I didn't want to assume something was done if it wasn't):

  1. GFF annotations ❓ done? a. minor augur changes, mostly done by Richard b. minor auspice changes

  2. Separate branch/node attributes a. probably LOTS of work in augur & auspice b. Is it worth it? What about internal (?) JSONs?? Need to look at this more closely

  3. BibTex ❓ done? a. Minor augur & auspice changes

  4. Add hidden attribute parsing to augur export ❓done? a. EASY

  5. augur export config composition ❗️ <-- need to resolve override questions a. What overrides what? What's minimum required? (EBH) b. Tweak/confirm command line config flags/args

  6. Schema works for multi-color-bys?!? (#184)

  7. Run all datasets on AWS and test extensively

  8. Merge BEAST branch

  9. Change color-by schema from {} -> [] (dict to list) ⬅️ 👀 ❗️ (emma says plz!)

  10. Should all meta-keys be under a 'meta' key in JSON? (#183)

  11. Bug #299 - True/False traits

  12. export v2 questions from Emma: a. What is intended function of URL field? Seems confused. (see auspice #734) Prob done 👩‍🔬(me) will test b. ~How should we generate keys? Need to know URL uniqueness for this. What would be most robust?~ c. Make export spit out less errors and warnings - totally overwhelming ATM. Related to a) and b) above Prob done 👩‍🔬 will test d. How does tip-frequency data integrate into new export v2 JSON - still separate? Integrated? Prob done - is this auto-detected and displayed if separate file present? ❓ e. ~Do we support default view in export v2? Are all aspects implemented?~ f. ~How does panel specification work? What will show by default? When will excluding one def. exclude it?~ g. Do we need --tree-name? In what circumstances? h. Do we support --output-sequence --reference --reference-translations yet? If not, can we comment these out for the time being?

  13. Add export/augur/JSON version explicitly to export JSONs (EBH)

  14. ~Fix weird --title quote requirements in export v2 (EBH)~

jameshadfield commented 5 years ago

I can't edit your messages -- unless you make me a collaborator on hello-world then there's no telling what damage would happen then. Maybe make these changes above then delete this message? 1: not done at all as far as i'm aware

  1. done
  2. done
  3. done
  4. ~will do today~ done
  5. will do today
  6. do you want me to take a look at this or do you want to do it? UPDATE: see https://github.com/nextstrain/augur/pull/326 12c -- done but it's validate that's the real problem. I'll have a look at that today. 12d -- you mean auspice? it makes a fetch call for EVERY dataset -- e.g. go to zika and look in the console. People told me this was the best way. 12g -- i'll write some more about this 12h -- could you write some more about what these are? I've never used them and can't work it out from the help messages

Do you mind if I take a look at 14 -- most other unix commands you have to specify a title as a single string in quotes, and then presumable they strip the quotations... weird stuff will happen if you want to put & ; ; rm -rf / into your title 😉 Update: see https://github.com/nextstrain/augur/pull/325

emmahodcroft commented 5 years ago

Yes sorry - I was pretty much meaning exactly what you did - just letting me know what was done! Since this is a nonsense repository I am not fussed about deleting messages/not repeating ourselves :P

RE 12d - I think the answer to both of these is yes, but my questions were: Will tip frequency data remain in its own JSON, not incorporated into the new v2 JSON? To make tip frequency data appear, one must both supply a tip-frequency-JSON and set the frequencies panel visible in 'panels'? (Or is this auto-detected somehow - that if a tip-frequency JSON is detected it will show the panel even if not set in panels?)

RE 12g - I have never used this but so far have not had to (no intensive testing done, though). If you can give a bit of context I can do some more directed testing. I think if we don't need it for all cases that would be great - sometimes you don't know head of time what you might want to make a tangle of! But would be good to know exactly when you need/don't.

RE 12h - You're as enlightened as I am! I just see them in the help message. I assume these will be used for supplying the bases for conserved sites in Auspice - so we can show the base even if there's no changes there. But that's a guess! If we aren't aiming to get this functional in v2 (I'd maybe say no, as I think getting this out sooner is better and we have a pretty full plate), then I'd vote we just comment them out in help and anywhere else, and work on them after v2 goes live.

(RE 1 - sorry got this mixed up with the author changes!)

  1. GFF annotations a. minor augur changes, mostly done by Richard b. minor auspice changes

  2. Separate branch/node attributes a. probably LOTS of work in augur & auspice b. Is it worth it? What about internal (?) JSONs?? Need to look at this more closely

  3. ~BibTex~ a. ~Minor augur & auspice changes~

  4. ~Add hidden attribute parsing to augur export~ a. ~EASY~

  5. augur export config composition ❗️ <-- need to resolve override questions a. What overrides what? What's minimum required? (EBH) b. Tweak/confirm command line config flags/args

  6. Schema works for multi-color-bys?!? (#184)

  7. Run all datasets on AWS and test extensively

  8. ~Merge BEAST branch~

  9. ~Change color-by schema from {} -> [] (dict to list)~

  10. Should all meta-keys be under a 'meta' key in JSON? (#183)

  11. Bug #299 - True/False traits ◀️ in progress

  12. export v2 questions from Emma: a. What is intended function of URL field? Seems confused. (see auspice #734) Prob done 👩‍🔬(me) will test b. ~How should we generate keys? Need to know URL uniqueness for this. What would be most robust?~ c. Make export spit out less errors and warnings - totally overwhelming ATM. Related to a) and b) above Prob done 👩‍🔬 will test d. How does tip-frequency data integrate into new export v2 JSON - still separate? Integrated? Prob done - is this auto-detected and displayed if separate file present? ❓ e. ~Do we support default view in export v2? Are all aspects implemented?~ f. ~How does panel specification work? What will show by default? When will excluding one def. exclude it?~ g. Do we need --tree-name? In what circumstances? h. Do we support --output-sequence --reference --reference-translations yet? If not, can we comment these out for the time being?

  13. Add export/augur/JSON version explicitly to export JSONs

  14. Fix weird --title quote requirements in export v2 ◀️ in progress

  15. Go through all tutorials and update a. Can we preserve v1 somewhere? People might be using this for reference/reminders and there's nothing more annoying that this kind of thing totally disappearing w/o warning. Maybe keep a link to v1 from v2 tutorials for a little while so people have time to adjust? b. Add optional config part to one or both tutorials

  16. Update & check all test files (e.g. replace --output, change to export v1/v2, and check all error/warning messages to ensure they are the things we are trying to test, and not accidental) a. Ensure v2 tests have combo of with/without CL/config

  17. Auspice 2.0 nucleotide colorby is broken. #749

jameshadfield commented 5 years ago

RE 12d ... Will tip frequency data remain in its own JSON

Yes

RE 12d ... is this auto-detected somehow - that if a tip-frequency JSON is detected it will show the panel even if not set in panels?

I think the other way round -- if "frequencies" is in panels then auspice will attempt to fetch the JSON. (I'm not sure if this is what it currently does, but that's what I think it should do!)

RE 12h - You're as enlightened as I am! I just see them in the help message.

Huh, the plot thickens!

RE 12g - I think if we don't need it for all cases that would be great - sometimes you don't know head of time what you might want to make a tangle of! But would be good to know exactly when you need/don't.

Not sure what to do here. As you've found out, this is only used by the server to figure out the drop-down options for the second tree -- if you specify it via the URL it "just works". Maybe best to move this to the available datasets JSON as that's more in line with what it's actually used for.

emmahodcroft commented 5 years ago

As you've found out, this is only used by the server to figure out the drop-down options for the second tree -- if you specify it via the URL it "just works"

Ah ok!! I hadn't actually parsed that. I will try and do some playing around to figure out the boundaries of exactly how it works. For all of the above ("12") questions my goal is to understand them well enough to ensure the --help and the docs I'm writing explain them clearly and correctly!

So with regard to 12d that's great - I can say this in the docs ("if you want to show frequencies you must supply a file and add 'frequencies' in panels...") and we just have to make sure it does indeed work that way :)