rm internal tools#1914
Conversation
|
|
||
| _basic_internal_tool: | ||
| asbtract: true | ||
| rules: |
There was a problem hiding this comment.
we don't have that in our internal destination definition, do we?
There is no reject: pulsar ?
There was a problem hiding this comment.
I think we added a condition to not add a pulsar tag to the expression tools under the id remote_resources
There was a problem hiding this comment.
Hmm, I am not sure whether to proceed or not with this one.
There are internal tools, including __DATA_FETCH__, that do not define a tool_type.
On the other hand, I would expect such cases to be covered by tool.requires_galaxy_python_environment == True. But this 10-year old code doesn't look very trustworthy to me...
That should not be very hard to check if we set up the debug handler. Afaik Galaxy loads a registry of all installed tools in memory, so it would be a matter of inserting a breakpoint, looking into the registry a and making sure tool.requires_galaxy_python_environment == True for all these tools.
Ofc this could also be achieved without the debug handler, for example changing the code so that when a handler finishes loading it writes this information to a file.
|
Settles it no @kysrpex ? |
I can only say that I am not sure, I would have to check more carefully to be sure. |
|
So I have analyzed the piece of code and cross referenced with the tools that we have mentioned in tools.yml: This means that any tool that is unversioned tool in the list For our tools this is true in:
For the other three tools, the tooltype is explicit in the tool datasouce:
This leaves the edge case of other tools that match the regex Where can I find more tools that would match that regex? If we can know this is safe to merge this PR. |
Now we have the conditions in tool_defautls I think we can remove this