Broken tools ids from ./run_functional_tests.sh -list
Hi all, Does anyone else see this problem with broken tool ids in the function test script? I found this because one of my own tools wasn't being recognised because for some reason the id was treated as _name= [sic]. This happens on the default branch: $ ./run_functional_tests.sh -list | grep "_name=" _name= RNA/DNA _name= Convert _name= Compute quality statistics _name= Draw quality score boxplot _name= DAVID $ hg branch default hg log -b default | head changeset: 9349:199b62339f26 user: jeremy goecks <jeremy.goecks@emory.edu> date: Thu Apr 11 08:44:42 2013 -0400 summary: Whitespace fixes for Vcf datatype. changeset: 9348:dbfc964167ae user: guerler date: Wed Apr 10 17:30:27 2013 -0400 summary: Enhance button for trackster visualization in data display viewer Have I found a recent regression, or is my system messed up somehow? Thanks, Peter
Peter, Thanks for reporting this issue, it looks like there might be a bug in tool_list.py, which I will be looking into. In the meantime, you should still be able to run functional tests for your tool by executing sh run_functional_tests.sh -id <tool_id> Where <tool_id> is the ID you have defined in the tool XML. The functional_tests.py script uses Galaxy's internal tool XML parser to generate the list of functional tests to run, so it should be able to find your tool and its tests. --Dave B. On 4/11/13 12:36:42.000, Peter Cock wrote:
Hi all,
Does anyone else see this problem with broken tool ids in the function test script? I found this because one of my own tools wasn't being recognised because for some reason the id was treated as _name= [sic].
This happens on the default branch:
$ ./run_functional_tests.sh -list | grep "_name=" _name= RNA/DNA _name= Convert _name= Compute quality statistics _name= Draw quality score boxplot _name= DAVID
$ hg branch default
hg log -b default | head changeset: 9349:199b62339f26 user: jeremy goecks <jeremy.goecks@emory.edu> date: Thu Apr 11 08:44:42 2013 -0400 summary: Whitespace fixes for Vcf datatype.
changeset: 9348:dbfc964167ae user: guerler date: Wed Apr 10 17:30:27 2013 -0400 summary: Enhance button for trackster visualization in data display viewer
Have I found a recent regression, or is my system messed up somehow?
Thanks,
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/
On Mon, Apr 15, 2013 at 2:15 PM, Dave Bouvier <dave@bx.psu.edu> wrote:
Peter,
Thanks for reporting this issue, it looks like there might be a bug in tool_list.py, which I will be looking into. In the meantime, you should still be able to run functional tests for your tool by executing
sh run_functional_tests.sh -id <tool_id>
Where <tool_id> is the ID you have defined in the tool XML. The functional_tests.py script uses Galaxy's internal tool XML parser to generate the list of functional tests to run, so it should be able to find your tool and its tests.
--Dave B.
Thanks for the clue Dave - you're right it is a bug in tool_list.py which uses its own quick and dirty XML parser. The bug was that is was confused by the use of the magic words 'id', 'name' or 'description' in the values. The patch below works for me, but assumes that there will not be a space between the key and the equals sign. The script remains a fragile hack - for instance if a tool's XML file split the <tool> tag over multiple lines, only the first line is used. Using a real XML parser instead would be better. The patch also addresses a potential overflow bug where it tests n = len(keys) - 1 as a possible key, and would then go out of bounds to get the value from list element n+1. The patch also replaces the use of -1 from find, using "in" is far clearer. The patch does not fix the non-standard 3 space indentation (PEP8 recommends 4 space indentation). Could you test this and commit it? Peter P.S. Yes, you're right for tool identifiers the ID is easy to get from the tool's XML file (that doesn't work for sections though). -- diff -r d8d3e4fe7c45 tool_list.py --- a/tool_list.py Fri Apr 12 11:27:17 2013 +0100 +++ b/tool_list.py Mon Apr 15 14:51:34 2013 +0100 @@ -35,14 +35,15 @@ for line in open("tools/"+tool) : if line.find("<tool ") != -1 and line.find("id") != -1 : keys = line.strip().split('\"') - n = 0 tool_info = dict() tool_info["desc"] = '' - while n < len(keys) : - if keys[n].find("id") != -1 : tool_info["id"] = keys[n+1].replace(' ', '_') - if keys[n].find("name") != -1 : tool_info["name"] = keys[n+1] - if keys[n].find("description") != -1 : tool_info["desc"] = keys[n+1] - n = n + 1 + for n in range(len(keys)-1): + if " id=" in keys[n]: + tool_info["id"] = keys[n+1].replace(' ', '_') + if " name=" in keys[n]: + tool_info["name"] = keys[n+1] + if " description=" in keys[n]: + tool_info["desc"] = keys[n+1] tool_infos.append(tool_info) break
Peter, Thanks for the contribution, I've verified that it works, and it has been committed in 9395:388e86c30bad. --Dave B. On 4/15/13 09:59:46.000, Peter Cock wrote:
On Mon, Apr 15, 2013 at 2:15 PM, Dave Bouvier <dave@bx.psu.edu> wrote:
Peter,
Thanks for reporting this issue, it looks like there might be a bug in tool_list.py, which I will be looking into. In the meantime, you should still be able to run functional tests for your tool by executing
sh run_functional_tests.sh -id <tool_id>
Where <tool_id> is the ID you have defined in the tool XML. The functional_tests.py script uses Galaxy's internal tool XML parser to generate the list of functional tests to run, so it should be able to find your tool and its tests.
--Dave B.
Thanks for the clue Dave - you're right it is a bug in tool_list.py which uses its own quick and dirty XML parser. The bug was that is was confused by the use of the magic words 'id', 'name' or 'description' in the values.
The patch below works for me, but assumes that there will not be a space between the key and the equals sign. The script remains a fragile hack - for instance if a tool's XML file split the <tool> tag over multiple lines, only the first line is used. Using a real XML parser instead would be better.
The patch also addresses a potential overflow bug where it tests n = len(keys) - 1 as a possible key, and would then go out of bounds to get the value from list element n+1.
The patch also replaces the use of -1 from find, using "in" is far clearer.
The patch does not fix the non-standard 3 space indentation (PEP8 recommends 4 space indentation).
Could you test this and commit it?
Peter
P.S. Yes, you're right for tool identifiers the ID is easy to get from the tool's XML file (that doesn't work for sections though).
On Mon, Apr 15, 2013 at 3:12 PM, Dave Bouvier <dave@bx.psu.edu> wrote:
Peter,
Thanks for the contribution, I've verified that it works, and it has been committed in 9395:388e86c30bad.
--Dave B.
Great, thank you :) Peter
participants (2)
-
Dave Bouvier -
Peter Cock