<html><head><style>body{font-family:Helvetica,Arial;font-size:13px}</style></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;"><div id="bloop_customfont" style="margin: 0px;"><span style="color: rgb(0, 0, 0); font-family: Helvetica, Arial; font-size: 13px;">Hi </span>João, Pi,<br></div><div id="bloop_customfont" style="margin: 0px;"><br></div><div id="bloop_customfont" style="margin: 0px;">You are both correct, for provenance it would be proper for the VEP installer to use frozen versions of dependent software set up by the installer. We’ll look into this for a future release.</div><div id="bloop_customfont" style="margin: 0px;"><br></div><div id="bloop_customfont" style="margin: 0px;">For now, as a proxy for this you could use Docker images tied to specific sub-release versions; these will be created at the time of creation of that sub-version and remain unchanged:</div><div id="bloop_customfont" style="margin: 0px;"><br></div><div id="bloop_customfont" style="margin: 0px;">docker pull ensemblorg/ensembl-vep:release_90.10</div><div id="bloop_customfont" style="margin: 0px;"><br></div><div id="bloop_customfont" style="margin: 0px;">HTH</div><div id="bloop_customfont" style="margin: 0px;"><br></div><div id="bloop_customfont" style="margin: 0px;">Will McLaren</div><div id="bloop_customfont" style="margin: 0px;">Ensembl Variation</div><div id="bloop_customfont" style="margin: 0px;"><br></div> <div id="bloop_sign_1512738108487380992" class="bloop_sign"></div> <br><p class="airmail_on">On 8 December 2017 at 12:13:51 pm, Pieter Neerincx (<a href="mailto:pieter.neerincx@gmail.com">pieter.neerincx@gmail.com</a>) wrote:</p> <blockquote type="cite" class="clean_bq"><span><div><div></div><div>Hi all,<br><br>I support João's request below. Here @ UMCG we just ran into the same issue this week, when we had to re-deploy software one of our clusters after major maintenance. Once we have performed validation experiments for a specific version we need to be able to re-install exactly that validated version; With the current INSTALL.pl script that is not possible without quite a bit of hacking :o...<br><br>Cheers,<br><br>Pi<br><br>> On 8 Dec 2017, at 12:44, João Eiras <joao.eiras@gmail.com> wrote:<br>> <br>> Hi.<br>> <br>> The VEP INSTALL.pl script, among the many dependencies that it pulls,<br>> pulls the Bio-HTS library.<br>> <br>> https://github.com/Ensembl/ensembl-vep/blob/release/90/INSTALL.pl#L809<br>> <br>> But it always pull the master branch. This means that if I download an<br>> old release of VEP, like version 85, and try to run that script today,<br>> it is broken because when release 85 was published, the Bio-HTS<br>> library had a different folder structure.<br>> <br>> Meanwhile, a fix for that difference in the folders was committed<br>> <br>> https://github.com/Ensembl/ensembl-tools/commit/066fa73a08529e917ac5f0979e2bd7df016a2f31#diff-51f0ea2952ae8378025549cdc377ecb6<br>> <br>> I seriously suggest you amend $biodbhts_zip_github_url to point to the<br>> version of Bio-HTS which was tested and verified compatible with the<br>> given VEP release, just like you did with samtools/htslib<br>> <br>> https://github.com/Ensembl/ensembl-tools/commit/a992bb0e31ba7bfe17d0e9abeefa87d89e60910f#diff-51f0ea2952ae8378025549cdc377ecb6<br>> <br>> A more reliable and safe way to do this would be to put two variables<br>> at the top of the script where $API_VERSION is defined, for instance,<br>> one variable for each library, with the branch/tag name that should be<br>> checked out and it compatible with that VEP release.<br>> <br>> For instance, I have an old VEP 87 instance, and the version of biohts<br>> compatible is 2.9.<br>> <br>> Then, as part of the development process you'd bump and test newer<br>> versions of these libraries.<br>> <br>> Thank you for your time.<br>> _______________________________________________<br>> Dev mailing list Dev@ensembl.org<br>> Posting guidelines and subscribe/unsubscribe info: http://lists.ensembl.org/mailman/listinfo/dev<br>> Ensembl Blog: http://www.ensembl.info/<br><br>-------------------------------------------------------------<br>phone: +31 6 143 66 783<br>e-mail: pieter.neerincx@gmail.com<br>skype: pieter.online<br>-------------------------------------------------------------<br><br>_______________________________________________<br>Dev mailing list Dev@ensembl.org<br>Posting guidelines and subscribe/unsubscribe info: http://lists.ensembl.org/mailman/listinfo/dev<br>Ensembl Blog: http://www.ensembl.info/<br></div></div></span></blockquote></body></html>