fix relative paths in raname json tree

coveralls commented 5 years ago

Coverage remained the same at 90.777% when pulling b8e57f4cd796b35e4c5e5468257ab1af17b23249 on antgonza:fix-relative-paths into edd17d9ca551812a3fb2c4b119ae1a5b8c4711c4 on qiita-spots:master.

charles-cowart commented 5 years ago

Stefan mentioned this after the merge:

https://github.com/qiita-spots/qp-deblur/pull/54#issuecomment-444387552

IMHO, it sounds like this file may be recreated with every SEPP insertion? I feel like I need another set of eyes to comment on this.

antgonza commented 5 years ago

I let @sjanssen2 comment but AFAIK that means that those files are specific to each release ... and that we should contact the release developers to coordinate for future releases, which will happen when a new GG release is out ...

sjanssen2 commented 5 years ago

@charles-cowart is right, those files get created for every native SEPP run (I don't know where exactly this is generated in Siavash's code) It is a workaround for pplacer, which cannot handle the full spectrum of taxon/node names used in Greengenes. Thus, the reference tree is renames, fragments get placed via the SEPP pipeline and the resulting tree names need to be back-translated by this.

For qiita, we know that we always operate with the same reference tree (Greengenes 13.8) and thus do not need to generate those files every time - especially since we break the SEPP pipeline into two pieces: obtaining placement (and storing those in the DB) and inserting placements into a tree.

Therefore, @antgonza is also right, those files are release specific - in fact file specific as there are some non deterministic (I think Siavash forgot to sort node) effects and this is the reason I added those files to the repo. Would be great to find a better solution instead of this quick and dirty work around.

Best, Stefan

charles-cowart commented 5 years ago

Thank you for commenting, Stefan!

qiita-spots / qp-deblur

fix relative paths in raname json tree #56