{bio}[foss/2021b] pangolin v3.1.16 w/ Python 3.9.6 + pangoLEARN v2021-10-18 and v2021-11-25

[sassy-crick]

(created using eb --new-pr)

[sassy-crick]

Requires:

• {bio}[foss/2021b] Biopython v1.79 w/ Python 3.9.6 #14308
• {bio}[GCC/11.2.0] Pysam v0.17.0 w/ Python 3.9.6 #14309
• {tools}[foss/2021b] snakemake v6.10.0 w/ Python 3.9.6 #14306
• {bio}[gompi/2021b] UShER v0.5.0 w/ Python 3.9.6 #14305
• {lib}[GCCcore/11.2.0] tbb v2020.3 #14304
• {data}[foss/2021b] scikit-learn v1.0.1 w/ Python 3.9.6 #14307
• {bio}[GCC/11.2.0] Kent_tools v422 #14300

[sassy-crick]

In light of the recently found omikron-variant of Sars-CoV-2, pangoLEARN and pango-designation have been updated. In order to keep the current version for comparison, I suggest to use the version prefix of pangoLEARN as a unique handle. This way, if and when new variant will come along, a quick update can be undertaken without doing in-place replacing.

[migueldiascosta]

In light of the recently found omikron-variant of Sars-CoV-2, pangoLEARN and pango-designation have been updated. In order to keep the current version for comparison, I suggest to use the version prefix of pangoLEARN as a unique handle. This way, if and when new variant will come along, a quick update can be undertaken without doing in-place replacing.

assuming the version of pangoLEARN is only relevant at runtime, couldn't it be a separate module, swapable after pangolin is loaded?

[boegel]

In light of the recently found omikron-variant of Sars-CoV-2, pangoLEARN and pango-designation have been updated. In order to keep the current version for comparison, I suggest to use the version prefix of pangoLEARN as a unique handle. This way, if and when new variant will come along, a quick update can be undertaken without doing in-place replacing.

assuming the version of pangoLEARN is only relevant at runtime, couldn't it be a separate module, swapable after pangolin is loaded?

It could be, but this approach makes sense to me too, I think (we briefly discussed this in the EasyBuild Slack too).
In some sense, it's a statement that these particular versions of pangoLEARN and pangolin are compatible.
If there's only a pangoLEARN module, you're left wondering whether you can use that in combination with pangolin that was installed with an older pangoLEARN.

[boegel]

Test report by @boegel
SUCCESS
Build succeeded for 2 out of 2 (2 easyconfigs in total)
node3147.skitty.os - Linux centos linux 7.9.2009, x86_64, Intel(R) Xeon(R) Gold 6140 CPU @ 2.30GHz (skylake_avx512), Python 3.6.8
See https://gist.github.com/d3d38306d9ba983d9a12aab6c691b873 for a full test report.

[boegel]

Test report by @boegel
SUCCESS
Build succeeded for 2 out of 2 (2 easyconfigs in total)
node3507.doduo.os - Linux RHEL 8.2, x86_64, AMD EPYC 7552 48-Core Processor (zen2), Python 3.6.8
See https://gist.github.com/cfdd035ff22e6f84fad6dd5148c4bab4 for a full test report.

[boegel]

@boegelbot please test @ generoso

[boegel]

lgtm

[boegelbot]

@boegel: Request for testing this PR well received on login1

PR test command 'EB_PR=14310 EB_ARGS= /opt/software/slurm/bin/sbatch --job-name test_PR_14310 --ntasks=4 ~/boegelbot/eb_from_pr_upload_generoso.sh' executed!

• exit code: 0
• output:

Submitted batch job 7432

Test results coming soon (I hope)...

- notification for comment with ID 985711623 processed

Message to humans: this is just bookkeeping information for me,
it is of no use to you (unless you think I have a bug, which I don't).

[boegelbot]

Test report by @boegelbot
SUCCESS
Build succeeded for 2 out of 2 (2 easyconfigs in total)
cns1 - Linux rocky linux 8.4, x86_64, Intel(R) Xeon(R) CPU E5-2667 v3 @ 3.20GHz (haswell), Python 3.6.8
See https://gist.github.com/6186d87cb2557df5ba61f0511ce41e0d for a full test report.

[boegel]

Going in, thanks @sassy-crick!