Hi Greg,
thanks for the clarification. Please see my comments below.
On Jul 20, 2014, at 3:22 PM, Peter Cock <[email protected]> wrote:
On Sun, Jul 20, 2014 at 6:23 PM, Björn Grüning <[email protected]> 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
Does that mean, circular dependencies will be no problem at all?
Do you consider including the converters into the datatypes as
best-practise? (These converters are implicit-galaxy-converters).
I would have only two repositories with circular dependencies.
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.
repo_x_to_y_converter and repo_y_to_x_converter would have dependencies
on datatype X and Y, so I do not see the need for a suite_definition ...
or it is some collection like the emboss_datatypes ...
My scenario is more that the converters are not tools, they are implicit
converters and should _not_ be displayed in the tool panel.
As far as I know they need to be defined inside the datatypes_conf.xml
file.
I think if circular dependencies are not a problem I will try to
implement a proof of concept. EMBOSS is now splitted:
https://github.com/bgruening/galaxytools/tree/master/datatypes/emboss_datatypes
Thanks Greg!
Bjoern
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/
_______________________________________________
galaxy-iuc mailing list
[email protected]
http://lists.bx.psu.edu/listinfo/galaxy-iuc
___________________________________________________________
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/
