Just to clarify, these changes will be implemented in the devel version of the package in the next cycle. The package in the release (next week) will be the same as it is now. Val 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