Closed jayoung closed 6 years ago
After discussion with the team we have not decided to change the host but we will try and make this distinction more clear in the documentation.
Thanks again. Given that the default host is the mirror, and Ensembl tell us that it only works with current and immediate previous versions of VEP, is it possible to include some sort of simple addition (hidden to the user) that would go like this (pseudocode):
if (versionRequested < (currentVersion-1) ) {
hostToUse <- 'ensembldb.ensembl.org'
## alternatively, simply warn the user that they need to specify a different host if they use an older version
}
That way there won't be a mysterious perl-derived error that's hard to track down. What do you think? thanks, Janet
I have reopened the issue and will look into this further
This is updated in the most recent devel version 1.21.4 - We now do not specify a default host so it will use the defaults from ensembl vep and advise in the documentation for US users to use the mirror for latency issues.
thanks very much - that solution makes a lot of sense
Hi Lori,
Submitting a github issue for something we already talked about on the support site (here: https://support.bioconductor.org/p/106976/#107036).
I ran into trouble using v88 of the VEP script with ensemblVEP, because the default host used by the bioc module (useastdb.ensembl.org) does not support anything other than the current or current minus 1 versions of the vep script (according to https://www.ensembl.org/info/data/mysql.html), and the script gives a very uninformative error if you try to use an older version of the vep script with the US host, whether on command line or through R/Bioc.
Here's the example code - this fails for me with a mysterious error:
when I specify a different host it works fine:
Would it be possible to change the default host when older versions of VEP are specified? I didn't expect that to be an issue, because on my real data I was using a local cached database and didn't think I was contacting any host at all. The same fix works on my data, though, so I'm happy:
Session info is below (truncated). Thanks,
Janet