On Aug 1, 2012, at 6:13 AM, SHAUN WEBB wrote:
c) The toolshed interface allows me to change the name of my tool. If I do this, then go to my Galaxy admin ui and try to get updates for my tool then it fails. Does it make sense to change a tools name after it is created? Is it possible to track previous tool names to avoid this happening?
This should not occur. Where are you able to change the name of your tool? You are not even allowed to change the name of the repository if it has been cloned (you can change the name of the repository as long as it has not been cloned). Can you send me a screen shot of hte page that allows you to change the name of your tool in the tool shed? I'll provide a fix as soon as I see where the issue lies.
OK, I guess I changed the name of my repository not tool. I then installed the tool via my local Galaxy instance. I can still change the name of the repository in my toolshed and when I try to get updates via Galaxy admin panel I get the following server error: "AttributeError: 'NoneType' object has no attribute 'repo_path'"
I cannot reproduce this behavior, so can you let me know the steps you use to do so? I need the page on which you are able to change the name of the tool shed repository in the tool shed after it has been cloned. Here is a screen shot of what should be occurring after the repository is cloned. Notice that the repository name is not alterable as it is no longer a text field.
Running toolshed tools:
I have no problems installing tools from toolsheds via Galaxy admin interface, however I can't get these tools to run. They stay Grey forever and look like this in the manage jobs table:
65 xxxx@xxxx.xx.ac.uk 0 minutes ago toolshed.g2.bx.psu.edu/repos/aaronquinlan/bedtools/bedtools_coveragebed_counts/0.1.0 new None None None
Do I have to set a tool runner or some other option for shed_tools?
No special configuration settings are required in your local Galaxy instance to to run tools installed from a tool shed. If they stay in the queued state, there must be an issue in your local Galaxy instance that causes installed tools as well as tools included in the distribution to remain queued. It has nothing to do with the fact they were installed.
No. All other tools run fine. Tools installed from either my toolshed or the Galaxy toolshed remain queued. If this is not a known issue then I will try to dig a little deeper to find the problem. Any pointers would be useful if you can think of why there should be a difference.
I've never seen this behavior before, and tools installed from the Galaxy main tool shed have been running on the main Galaxy server for some time. No changes were made to the job components, so executing tools installed from tool sheds is no different in that regard from running tools included in the distribution. It's difficult to tell you where to begin looking for the cause of the problem.