kat 1.x vs kat 2.x problem

[tgac]

kat 1.x vs kat 2.x problem

[maplesond]

Hi Torsten,

Not sure what you mean by complete replacement. The core outputs (k-mer counts and matrices) should be identical between V1 and V2, although V2 does produce additional output. The main difference is that V2 has the option of using fast(a/q) directly as input and using jellyfish to count internally, which can impact any pipeline that KAT is part of if that feature is used. I haven't tried directly dropping KAT2 into a KAT1 pipeline but I suspect in theory this should work (maybe with some minor modifications), providing jellyfish 1 is replaced with jellyfish 2 as well.

So I'm not sure we are in the same category as bowtie / python where behaviour is very different. As far as homebrew goes I'd suggest we leave the executable name the same and just allowing the latest version to override the previous in the "bin" dir. If users are interested in comparing versions they can still do this by using absolute paths to the homebrew Cellar. Maybe I've misunderstood something though, so if you could point out some use cases where there are clear problems I'll take another look.

Cheers,
Dan

[tseemann]

For kat 2.x to be deployed using the same command name kat as kat 1.x then it should be 100% compatible API and the support the 1.x command line interface and preferably output files too.

I never used kat until doing the workshops with @bjclavijo recently, so I don't know what's really different, hence this question.

Clearly people are using it in pipelines and tutorials and there are command lines written already. So if kat 2.x breaks all those things that is not good.

[maplesond]

I see your point, by the same logic now is not the time to make a big change to the interface by changing the executable name. I'll keep this in mind for V3.

[maplesond]

I think in this case I would prefer to keep the executable name the same as I would like to migrate users away from V1 and onto V2(.1). Despite a slightly different interface there is no functionality in V1, that can't be replicated in V2, therefore it should be seen as a complete replacement, not as a separate piece of software used for different purposes (like bowtie / python).

Unfortunately, this does mean some users could end up with broken pipelines but on the other hand, swapping in and out different versions of software from a pipeline is a dangerous thing to do regardless of any interface changes so I don't think many users will be too upset by this. Feel free to reopen if you wish to continue the discussion but for now I'll close the case.