DEXSeq - resolve HTSeq/numpy depenency version mismatch

[lparsons]

• I have read the guidelines for bioconda recipes.
• This PR adds a new recipe.
• AFAIK, this recipe is directly relevant to the biological sciences (otherwise, please submit to the more general purpose conda-forge channel).
• This PR updates an existing recipe.
• This PR does something else (explain below).

I've pinned the version of numpy used for HTSeq in #12467. However, since this requires an older htseq recipe that doesn't have numpy properly pinned, I'm forcing it here. These can be removed when we get various fixes from DEXSeq upstream areyesq89/DEXSeq#1.

[lparsons]

Just wondering if this approach is kosher, or if there is a better way to fix this (fixing old HTSeq version(s)?). Ping @bgruening and @dpryan79 since you guys seem like gurus... 😉

[dpryan79]

I never get the numpy pinning stuff right, so I'll defer to Björn :)

[lparsons]

Well @epruesse merged the HTSeq fix in #12467. However:

1. I don't really have a way to test that it works
2. At best, it applied to the latest HTSeq (0.11), but that won't help for DEXSeq since it requires an older version (<0.10).

[bgruening]

@lparsons can we not fix the old htseq-count recipe for 0.9.1.

[lparsons]

@bgruening I don't think I follow you. Are you saying we cannot fix the old HTSeq? Can you tell me:

1. Is requiring a specific numpy version and specific HTSeq version for DEXSeq the best way to make DEXSeq actually work? Since DEXSeq requires an old HTSeq version, this was the best way found to (hopefully) fix it.

2. Is the way I pinned numpy for HTSeq sufficient to fix the current version of HTSeq

[bgruening]

@lparsons I think we should fix the old htseq-count recipe.

Is requiring a specific numpy version and specific HTSeq version for DEXSeq the best way to make DEXSeq actually work? Since DEXSeq requires an old HTSeq version, this was the best way found to (hopefully) fix it.

It has a good chance to fix it. But I would prefer to fix htseq-count 0.9.1 instead.

Is the way I pinned numpy for HTSeq sufficient to fix the current version of HTSeq

I don't know, probably. We should use - {{ pin_compatible('numpy') }} in run dependencies if we can, but this is only working when you have host dependencies as well.

[lparsons]

I agree, I'd rather fix the old HTSeq recipes, but I'm not clear on how to do that. Create a subdir under HTSeq for the version perhaps? And pick a build number higher than the historic build number used for that version?

…

-- Lance Parsons - Scientific Programmer Carl C. Icahn Laboratory - Room 136 Lewis-Sigler Institute for Integrative Genomics Princeton University On Tue, Dec 4, 2018 at 3:52 PM -0500, "Björn Grüning" <notifications@github.com<mailto:notifications@github.com>> wrote: @lparsons<https://github.com/lparsons> I think we should fix the old htseq-count recipe. Is requiring a specific numpy version and specific HTSeq version for DEXSeq the best way to make DEXSeq actually work? Since DEXSeq requires an old HTSeq version, this was the best way found to (hopefully) fix it. It has a good chance to fix it. But I would prefer to fix htseq-count 0.9.1 instead. Is the way I pinned numpy for HTSeq sufficient to fix the current version of HTSeq I don't know, probably. We should use - {{ pin_compatible('numpy') }} in run dependencies if we can, but this is only working when you have host dependencies as well. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub<#12468 (comment)>, or mute the thread<https://github.com/notifications/unsubscribe-auth/AAnYCBUpCUB6y1Humg4FjWFARNPa3lL9ks5u1uCRgaJpZM4Y_ap6>.

[bgruening]

That sounds alright to me :)

[lparsons]

OK, submitted #12490 which should hopefully resolve this. Once tested I'll update/delete this as needed.

[lparsons]

I believe that #12490 has eliminated the need for this PR, closing.