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

