[BioC] ensemblVEP, variant_effect_predictor versions and release schedule

Valerie Obenchain vobencha at fhcrc.org
Fri Oct 11 01:20:40 CEST 2013


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.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 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
>
>



More information about the Bioconductor mailing list