Please see my comments below.

On Jul 20, 2014, at 3:22 PM, Peter Cock <p.j.a.c...@googlemail.com> wrote:

> On Sun, Jul 20, 2014 at 6:23 PM, Björn Grüning <bjo...@gruenings.eu> wrote:
>> Hi,
>> 
>> single datatype definitions only work if you haven’t defined any converters.
>> Let's assume I have a datatype X and want to ship a X -> Y converter (Y -> X
>> is also possible), we will end up with a dependency loop, or? The X
>> repository will depend on the Y repository, but Y is depending on X, because
>> we want to include a Y -> X converter.
>> 
>> Any idea how to solve that?

I don't see a problem here, so I'm hoping I'm correctly understanding the issue.

If we have:

repo_x contains the single datatype X
repo_y contains the single datatype Y
repo_x_to_y_converter contains a tool that converts datatype X to datatype Y 
(this repository also defines 2 dependency relationships, one to repo_x and 
another to repo_y)
repo_y_to_x_cenverter contains a tool that converts datatype Y to datatype X 
(this repository also defines 2 dependency relationships, one to repo_x and 
another to repo_y)

Now if we want to install both the repo_x_to_y_converter and the 
repo_y_to_x_cenverter automatically whenever either one is installed, we have 2 
options:

1) define a 3rd dependency relationshiop for repo_x_to_y_converter to depend on 
repo_y_to_x_cenverter and, similarly a 3rd dependency relationshiop for 
repo_y_to_x_cenverter on repo_x_to_y_converter.  This does indeed
create a circular repository dependency relationship, but the Tool Shed 
installation process will handle it correctly, installing all 4 repositories 
with proper dependency relationships created between them

2) Instead of creating a circlular dependency relationship between 
repo_x_to_y_converter and repo_y_to_x_cenverter, create an additional 
suite_definition_x_y repository (of type "repository_suite_definition" that 
defines relationships to repo_x_to_y_converter and  repo_y_to_x_cenverter, 
ultimately installing all 4 repositories, but without defining any circular 
dependency relationships.

Either of the above 2 scenarios will correctly install the 4 repositories.

Let me know if I'm missing something here.

Thanks!

Greg

> 
> Excellent example!
> 
>> How to handle versions of datatypes? Extra repositories for stockholm 1.0
>> and 1.1? If so ... the associated python file (sniffing, splitting ...)
>> should be also versioned, or? What happend if I have two stockholm.py files
>> in my system?
> 
> Potentially you might need/want to define those as two different
> Galaxy datatypes?
> 
>> @Peter, can we create a striped-down, python only biopython egg? All parsers
>> should be included, Bio.SeqIO should be sufficient I think.
> 
> Right now, yes in principle (and this is fine from the licence point of view),
> but in practise this is a fair chunk of work. However, we are looking at
> this - see https://github.com/biopython/biopython/issues/349
> 
> Peter
> 
> ___________________________________________________________
> Please keep all replies on the list by using "reply all"
> in your mail client.  To manage your subscriptions to this
> and other Galaxy lists, please use the interface at:
> http://lists.bx.psu.edu/
> 
> To search Galaxy mailing lists use the unified search at:
> http://galaxyproject.org/search/mailinglists/
> 


___________________________________________________________
Please keep all replies on the list by using "reply all"
in your mail client.  To manage your subscriptions to this
and other Galaxy lists, please use the interface at:
  http://lists.bx.psu.edu/

To search Galaxy mailing lists use the unified search at:
  http://galaxyproject.org/search/mailinglists/

Reply via email to