Please retire tabix

[jkbonfield]

The tabix recipe (see https://github.com/bioconda/bioconda-recipes/blob/master/recipes/tabix/0.2.6/meta.yaml) uses legacy copy of tabix / bgzip here: https://github.com/samtools/tabix. This package hasn't been supported for nearly a decade. It has been replaced by bgzip and tabix binaries in htslib: https://github.com/samtools/htslib which have since had bug fixes and some major performance improvements.

There are several packages with the tabix recipe as dependencies. Please consider removing this recipe and encouraging the users to switch to htslib (most of which already do have it as a dependency anyway).

Note this package is installed quite a lot - it's had 80K installs.

[winni2k]

Is there a bug-fix-only replacement available for these packages in HTSlib? That is, if I have a piece of code that relies on tabix 0.2.6, is there a version of tabix in htslib that has the same API and that I can therefore use as a drop-in replacement?

[winni2k]

Here is an example of some code (SNPTools) that still uses tabix v0.2.5: #15622.

However, I never managed to get to a working version of this recipe. Perhaps SNPTools has decayed and is no longer relevant to this conversation...

[jmarshall]

Bioconda's htslib package already contains drop-in replacements for the bgzip and tabix commands, and always has. Most of the bioconda packages that specify a dependency on the tabix package also depend on samtools or bcftools so are also getting htslib's versions of these executables — so I suspect it is currently random depending on installation order which version of …/bin/tabix etc an environment ends up with. Brillant.

(Yes, I recall your PR #15624 that made the tabix-0.2.5 package also install libtabix.* (hence bringing non-commandline “APIs” into play), and had noted that the one thing that needed it has never been merged…)

What is really needed is for Bioconda's htslib package to declare that it provides the functionality of a tabix package so satisfies a request for that package, but I don't believe conda packaging has that capability. Failing that, there are about 16 PRs to be made; I have drafts of a few of them…

[jkbonfield]

The vast bulk of package installs are for 0.2.6 which installs just the command line utilities, so there is no issue there and indeed you'll accidentally be getting the htslib copies a lot of the time anyway!

Then there's 0.2.5 recipe which I didn't realise until just now had something different in it. Ugh! I assumed it was the same as 0.2.6, especially given the current git clone of tabix claims to actually be 0.2.5 https://github.com/samtools/tabix/blob/master/main.c#L11 (but is packaged as 0.2.6 - confused yet?).

For API compatability, to be honest I don't know what differences there are between libtabix code and htslib, but I'd expect them to be compatible given we'd taken great pains to not break the API over the years. It's likely there are some small ABI changes though. If there is one single package out there which requires libtabix, then IMO if you really do want this exact version and can't test it against htslib then the build recipe for that package should download the tabix source in-situ to build and link against libtabix.a (not .so) so the binary includes the appropriate dependency. (Edit: and don't install the lib.)

[winni2k]

That sounds like a good way to proceed for SNPTools.

[dpryan79]

Tabix now just installs a recent htslib version as a dependency, so if someone mistakenly runs "conda install tabix" they get htslib instead. I'm currently removing the absurdly old recipes so no one gets the crazy idea to rebuild them (#28152 ). I'll also go through and try and fix the various recipes that mistakenly list tabix rather than htslib as a run-time dependency.

[kpalin]

I wouldn't call it a mistake. I think "conda install tabix" is a fairly intuitive way of installing tabix, more so than "conda install htslib". Anyway, things are sorted now.