Question: ensemblVEP, variant_effect_predictor versions and release schedule
0
gravatar for Guest User
6.1 years ago by
Guest User12k
Guest User12k wrote:
Dear Valerie, Currently, the documentation for your ensemblVEP package (BioC 2.13) indicates that 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 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 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 ? 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.
ensemblvep • 728 views
ADD COMMENTlink modified 6.1 years ago by Valerie Obenchain6.7k • written 6.1 years ago by Guest User12k
Answer: ensemblVEP, variant_effect_predictor versions and release schedule
0
gravatar for Valerie Obenchain
6.1 years ago by
United States
Valerie Obenchain6.7k 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. 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 from ensemble release 73 is required. > > I was wondering if had any plans on supporting different versions of ensembl's 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 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 ? 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. >
ADD COMMENTlink written 6.1 years ago by Valerie Obenchain6.7k
On Fri, Oct 4, 2013 at 3:30 PM, Valerie Obenchain <vobencha@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 from ensemble release 73 is >> required. >> >> I was wondering if had any plans on supporting different versions of >> ensembl's 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 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 ? 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. >> >> > ______________________________**_________________ > Bioconductor mailing list > Bioconductor@r-project.org > https://stat.ethz.ch/mailman/**listinfo/bioconductor<https: stat.et="" hz.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]]
ADD REPLYlink written 6.1 years ago by Michael Lawrence11k
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@gene.com>wrote: > On Fri, Oct 4, 2013 at 3:30 PM, Valerie Obenchain <vobencha@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 from ensemble release 73 is > >> required. > >> > >> I was wondering if had any plans on supporting different versions of > >> ensembl's 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 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 ? 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. > >> > >> > > ______________________________**_________________ > > Bioconductor mailing list > > Bioconductor@r-project.org > > https://stat.ethz.ch/mailman/**listinfo/bioconductor< > https://stat.ethz.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@r-project.org > https://stat.ethz.ch/mailman/listinfo/bioconductor > Search the archives: > http://news.gmane.org/gmane.science.biology.informatics.conductor > [[alternative HTML version deleted]]
ADD REPLYlink written 6.1 years ago by Vincent J. Carey, Jr.6.3k
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: sta="" t.ethz.ch="" mailman="" listinfo="" bioconductor=""> > > Search the archives: http://news.gmane.org/gmane.** > > > science.biology.informatics.**conductor<http: news.gmane.org="" gm="" ane.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 > >
ADD REPLYlink written 6.1 years ago by Valerie Obenchain6.7k
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
ADD REPLYlink written 6.1 years ago by Valerie Obenchain6.7k
Please log in to add an answer.

Help
Access

Use of this site constitutes acceptance of our User Agreement and Privacy Policy.
Powered by Biostar version 16.09
Traffic: 434 users visited in the last hour