package_trinity_2_1_1 installation fails compiling samtools

[lparsons]

After some additional testing and reinstallation, it seems that some update broke the installation of package_trinity_2_1_1, the trinity dependency fails with this error: https://gist.github.com/lparsons/6a73f86e7c5faa5e570c63870e9aa9dd

[ericenns]

I am also getting this same error on Centos 6

[abretaud]

It fails because it cannot find zlib include dir while compiling the samtools version bundled in the trinity plugins dir.
I don't remember if there is a reason to compile this bundled version instead of using the galaxy samtools package. I'll have a look

[lparsons]

@abretaud Just wondering if you've made any progress on this before I start looking into it myself.

[abretaud]

Sorry, I didn't find the time to investigate more, I think the best would be to patch the trinity plugins Makefile to avoid building dependencies bundled in trinity tarball. It is done like this in the bioconda recipe: https://github.com/bioconda/bioconda-recipes/blob/master/recipes/trinity/trinity-plugins.makefile.clean.patch
I'm not sure if I'll have time to work on it until next week, so no problem if you want to look at it

[lparsons]

That's for the pointers @abretaud. I didn't get to look at it much, but I did confirm the problem comes from sourcing env.sh from the zlib package. Not sure why, but it interferes with samtools make process. I'm thinking your are probably right to avoid building at least samtools. Is there a "standard" way to apply patches in galaxy packages?

[lparsons]

A bit more digging and it seems like having C_INCLUDE_PATH and CPLUS_INCLUDE_PATH pointing to zlib 1.2.8 is causing the issue. If I unset those, samtools builds fine, and they are not set in the various package_samtools_0_1_19 tool_dependency.xml files. So a couple of options:

1. Remove the zlib path from C_INLUDE_PATH and CPLUS_INCLUDE_PATH prior to building trinity-plugins. This avoids patching Makefiles, etc.
2. Patch the Makefile to avoid building samtools and instead provide samtools as a galaxy dependency. The problem here is that the trinity tools already use samtools 1.2 as a dependency, yet trinity builds 0.1.19. Thus this could change behavior and/or break things if trinity is expecting 0.1.19.

@abretaud @bgruening Comments, suggestions?

[lparsons]

Hmmm... Actually, looking at this now, it's not clear that package_trinity_2_1_1 ever actually uses the built samtools 0.1.19. There is no directive to move trinity-plugins/samtools and the path is never set for that subdirectory either. Perhaps simply avoiding building samtools will work?