Hi Thomas, I've started to add support for versions 67 and 73+. I assume you're still using version 67 and have the data cached. How are you calling the script right now? Do you use the --cache flag or --offline flag? Also, please remind me of (point me to) the plug-in you're using so I can test that. Thanks. Valerie On 10/10/2013 04:20 PM, Valerie Obenchain wrote: > Hi all, > > As of this release ensemblVEP will support multiple versions of the > script. This will start with version 73 and move forward. One old > version (67) will be included as a backwards test case. > > The plan is for only the most current version to have the option to > query the web. Past versions will query data the user has cached. If you > are using an old version of the script hopefully you have saved the > appropriate version of the data. > > Older versions of the data are available for download but they are not > the same format which is downloaded when you 'create a cache'. This > prevents the use of the variant_effect_predictor.pl script to query old > versions. So, we'll plan to save the cached data from 73 forward. > > Val > > > > On 10/05/2013 07:14 AM, Vincent Carey wrote: >> The basic situation seems reminiscent of MLInterfaces. We want to >> bridge between >> a familiar environment (R/bioc) and some useful utilities that need not >> be in sync with bioc. >> >> I don't know much about the VEP perl utility. It seems to me that it >> could be easy to >> support multiple local versions of the _perl script_ by exposing >> >> ensemblVEP:::.getVepPath() >> >> and allowing the user to define the specific script to be called. >> >> This part: >> >> 'VEPParam(basic=basicOpts(), input=inputOpts(), cache=cacheOpts(), >> output=outputOpts(), identifier=identifierOpts(), >> colocatedVariants=colocatedVariantsOpts(), >> dataformat=dataformatOpts(), filterqc=filterqcOpts(), >> database=databaseOpts(), advanced=advancedOpts(), ...)' >> >> is a nice way of organizing the extensive command line options, but as >> the >> utility evolves, this may prove fragile. It could also be made more >> flexible, but >> use cases and specific issues with multiple local versions should be >> spelled >> out. >> >> >> >> On Sat, Oct 5, 2013 at 8:37 AM, Michael Lawrence >> <lawrence.michael at="" gene.com="" <mailto:lawrence.michael="" at="" gene.com="">> wrote: >> >> On Fri, Oct 4, 2013 at 3:30 PM, Valerie Obenchain >> <vobencha at="" fhcrc.org="" <mailto:vobencha="" at="" fhcrc.org="">>wrote: >> >> > Hi Thomas, >> > >> > I agree the changes to the package have been rapid and I >> apologize for >> > causing you grief. The question you ask is a good one. It's >> difficult to >> > know how to best 'freeze' this package for a given release given >> that both >> > the data and the api are changing (and not necessarily in sync). >> > >> > We are investigating other approaches and hope to have a solution >> soon. >> > ensemblVEP is not the only package that falls in this category >> so the >> > solution needs to have a wider scope. One idea is to move >> emsemblVEP to >> > AnnotationHub. The idea would be that the user would no longer >> need the >> > perl script locally. This would allow us to create a more >> consistent layer >> > between the user and the backend and offer version control. >> > >> > >> But it sounds like this idea would simply defer the problem to the >> AnnotationHub side. That is, if someone has a customized Ensembl >> database, >> they will need to keep their local AnnotationHub in sync (are >> local hubs >> supported yet?). One way forward would be for ensemblVEP to support >> multiple versions of the script (as Thomas suggested). There would >> be some >> policy that versions are only supported for some duration after >> release. >> >> >> >> > Valerie >> > >> > >> > On 10/03/2013 12:52 PM, Thomas Sandmann [guest] wrote: >> > >> >> Dear Valerie, >> >> >> >> Currently, the documentation for your ensemblVEP package (BioC >> 2.13) >> >> indicates that variant_effect_predictor.pl >> <http: variant_effect_predictor.pl=""> from ensemble release 73 is >> >> required. >> >> >> >> I was wondering if had any plans on supporting different >> versions of >> >> ensembl's variant_effect_predictor.pl >> <http: variant_effect_predictor.pl=""> script with your ensemblVEP >> >> package. >> >> >> >> As far as I know, ensembl is on a pretty rapid release schedule, >> most >> >> likely faster than the 6 month schedule of BioC. This is often >> also too >> >> fast for many users (and our company), who update less >> frequently than >> >> ensembl itself, relying on previous ensembl and >> variant_effect_predictor >> >> versions. For example, we are currently still using the database >> schemas >> >> and tools of ensembl 67. >> >> >> >> The variant_effect_predictor.pl >> <http: variant_effect_predictor.pl=""> script also evolves with the >> ensembl >> >> releases. For example, new command line parameters have been >> added in >> >> recent versions ( e.g. --database, --dir_cache, --dir_plugins) >> and others >> >> have been modified (e.g. the handling of plugins). >> >> >> >> Would you mind sharing your thoughts on how you are planning to >> support >> >> past and / or future versions of variant_effect_predictor.pl >> <http: variant_effect_predictor.pl=""> ? For >> >> example, are you planning to explicitly support a single version >> with every >> >> ensemblVEP release ? Or would it be possible to include a >> 'version' >> >> parameter in ensemblVEP to switch between parameters supported >> by different >> >> versions of the perl script ? >> >> >> >> Thanks a lot for any insights, >> >> Thomas >> >> >> >> -- output of sessionInfo(): >> >> >> >> NA >> >> >> >> -- >> >> Sent via the guest posting facility at bioconductor.org >> <http: bioconductor.org="">. >> >> >> >> >> > ______________________________**_________________ >> > Bioconductor mailing list >> > Bioconductor at r-project.org <mailto:bioconductor at="" r-project.org=""> >> > >> >> https://stat.ethz.ch/mailman/**listinfo/bioconductor<https: stat.e="" thz.ch="" mailman="" listinfo="" bioconductor=""> >> >> > Search the archives: http://news.gmane.org/gmane.** >> > >> >> science.biology.informatics.**conductor<http: news.gmane.org="" gmane="" .science.biology.informatics.conductor=""> >> >> > >> >> [[alternative HTML version deleted]] >> >> _______________________________________________ >> Bioconductor mailing list >> Bioconductor at r-project.org <mailto:bioconductor at="" r-project.org=""> >> https://stat.ethz.ch/mailman/listinfo/bioconductor >> Search the archives: >> http://news.gmane.org/gmane.science.biology.informatics.conductor >> >> > > _______________________________________________ > Bioconductor mailing list > Bioconductor at r-project.org > https://stat.ethz.ch/mailman/listinfo/bioconductor > Search the archives: > http://news.gmane.org/gmane.science.biology.informatics.conductor -- Valerie Obenchain Program in Computational Biology Division of Public Health Sciences Fred Hutchinson Cancer Research Center 1100 Fairview Ave. N, M1-B155 P.O. Box 19024 Seattle, WA 98109-1024 E-mail: vobencha at fhcrc.org Phone: (206) 667-3158 Fax: (206) 667-1319