These are chat archives for dereneaton/ipyrad

11th
Jan 2016
Isaac Overcast
@isaacovercast
Jan 11 2016 01:29
.loci format turned out to be quite easy to generate post-filtering, got the furst full run of step7 with formatted .loci out working. w00t. vcf next.
Isaac Overcast
@isaacovercast
Jan 11 2016 02:36
Pull a new from master. I added a script called 'ipyrad_update_version.py', it takes one arg which is the new version. If you make all your changes and commit them, then do './ipyrad_update_version.py 0.1.x' or whatever, it'll update init.py, push init, add a new tag, push the tag and commit the changes. works much bettter. try it out and let me know what you think.
Isaac Overcast
@isaacovercast
Jan 11 2016 16:28
I had a wicked idea.
load.load_assembly() should load the requested assembly. Then it can load a new dummy tmp assembly, test for any newly added parameters and update the current paramsdict if necessary. This way we won't have to keep rebuilding assemblies from scratch every time we update paramsdict, which is a pain.
Deren Eaton
@dereneaton
Jan 11 2016 17:41
That sounds brilliant.
It might have to check Sample objects as well.
Isaac Overcast
@isaacovercast
Jan 11 2016 17:54
Ok, i'll work on it, shouldn't be too hard.
Just pushed a new commit for step7. Here's the commit log: "step 7 now finishes and writes out most output files"
W0000000t
loci2migrate is still broken. vcf w/ genotype likelihoods is broken. Everything else works.
Deren Eaton
@dereneaton
Jan 11 2016 20:49
Awwww man!
Two thoughts on ipyrad_update_version.py:
1) Let's give it a shorter name (e.g., versioner.py)?
2) Let's add to it code that tells __init__ to set the DEBUG level to "ERROR". We can always set it back to DEBUG while we're hacking. But this will ensure we never put out a version with debugging turned on.
Isaac Overcast
@isaacovercast
Jan 11 2016 21:48
Good idea. I'll do it real quick
Ok, for the auto-assembly updater I can foresee some complexity. Just diffing the assemblies and copying from a blank one to the new one is pretty easy, you get the stock default for the new param. What about if we remove or rename a parameter? I guess there's two options i can see:
1) the 'light-touch' version: auto-update only ever adds new parameters, never deletes or modifies
2) the 'rough-touch' version: auto-update actually creates a new params dict, populates it with all the values it actually recognizes from the old one, and then copies that new one into the current assembly
Isaac Overcast
@isaacovercast
Jan 11 2016 22:37
Also load_assembly() could have a forceupdate flag?
Isaac Overcast
@isaacovercast
Jan 11 2016 22:55
I think we have to do it the second way, guarantees compatibility for the future, less messy. Have to be careful about informing user of the keys and values that are changing/vanishing.
Deren Eaton
@dereneaton
Jan 11 2016 22:57
I agree that sounds like the best way.
Isaac Overcast
@isaacovercast
Jan 11 2016 22:59
I also decided to save a hidden backup copy before making the overwrite, just for the hell of it.
Deren Eaton
@dereneaton
Jan 11 2016 23:10
I might change the indels parameters to "max_indels_stack" and "max_indels_locus", or "max_indels_within" and "max_indels_across".
the idea being I want one for step3 and another for step6.
Deren Eaton
@dereneaton
Jan 11 2016 23:59
Or maybe meh: I could hardcode or put in hackerzdict the max_indels for within-sample clusters. I don't think this should generally be more than 3-5.