-
Notifications
You must be signed in to change notification settings - Fork 1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
EDAM tool panel #10592
EDAM tool panel #10592
Conversation
It's just the unit tests that mock out a config object in various places. Want me to fix that ? |
Sure, that'd be ace! |
57a1457
to
ed4e451
Compare
Downloading this file now from beta_edam_ontology_url. Can you rebase out config/EDAM_1.23.tsv ? I just gave it a go, it looks nice! |
Co-authored-by: Marius van den Beek <[email protected]>
I like that, it is a consistent way to read the panel. |
ed4e451
to
fcdaeb8
Compare
Re-add uncategorized, remove WFs, not sure working
6b49ed4
to
920549b
Compare
@@ -823,7 +1013,10 @@ def quick_load(tool_file, async_load=True): | |||
integrated_elems[key] = tool | |||
|
|||
if async_load: | |||
self._load_tool_panel() | |||
if self.app.config.enable_beta_edam_toolbox: |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can we instead make this an API parameter and have this more of a dynamic view of the toolbox?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
That definitely sounds like a better API. Would you have any suggestions for that refactoring? (It's been a while since I've done dev type things) Doing both the edam version and non-edam version parsing, and building two internal toolboxes?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Just following up here @jmchilton in case you had any opinions on the implementation :)
I haven't tried this yet, but it aligns a lot with what @juleengraham has been working towards to support multiple user/admin/upstream defined toolsets in the tool panel. Have you followed that work? (I'm also out of date on the status of that, and haven't tried this yet, but I'm trying to catch up and wanted to comment before I forget!) |
That sounds fantastic, I have not heard about it, or followed it at all. Is there a tracking issue somewhere or so? |
@hexylena Dannon is referring to PR #9996. I actually brought up this EDAM work in our JHU meeting last week and briefly started a discussion about how the two might be related. At the time we weren't really sure what EDAM tags were. I'm sure we're going to talk about it more later today. I know in your original issue, you mention admins wanting to have their own lists and I think that would be a great way to connect these two projects. Correct me if I'm wrong but EDAM tags seem to be a part of a tool's configuration (so specified by the tool's creator/maintainer?), but more standardised because EDAM comes from a biological background/definition. |
@juleengraham ah neat, I hadn't seen that. Admins having their own organisations of the tool panel was definitely discussed in the original, but I think it was potentially a bit orthogonal to the goals of an EDAM view? (i.e. I didn't have bandwidth to tackle that problem.)
This is exactly correct. Tool developers tag their tools with the functions and topics of the tool. It's not an admin or user controlled feature. But it could definitely fit into the "one of many" views of a tool panel, like it seems you've been tasked with! |
@hexylena noted! The toolsets weren't necessarily intended to be based on EDAM tags but I could see that being a use case. I started out working based on the EU's pre-curated sets (https://github.com/usegalaxy-eu/usegalaxy-eu-tools) but I've changed the implementation a bit in hopes that it'll be more user-friendly for the admins. I think for now, the lists were meant to be created by the admin of the instance and no individual users |
As an optional / dev setup this looks fine to me and certainly is a great incentive for more EDAM. Would you be opposed to merging as is (after resolving conflicts) @jmchilton @dannon @juleengraham ? |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can you resolve conflicts @hexylena ?
Yes, absolutely @mvdbeek |
Resolved. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Approve after linting and tests are passed. Sorry for dropping the ball on the review of this. I'd like to take a pass at making it a bit more dynamic but this is a cool step forward. Thanks so much!
No worries. would love for it to be more dynamic too. I look forward to our
multi view toolbox future!
John Chilton <[email protected]> schrieb am Do., 7. Jan. 2021, 23:20:
… ***@***.**** approved this pull request.
Approve after linting and tests are passed. Sorry for dropping the ball on
the review of this. I'd like to take a pass at making it a bit more dynamic
but this is a cool step forward. Thanks so much!
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#10592 (review)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AADP7O4MA7H2MDMILWNZYOLSYYXUJANCNFSM4TEYJZAQ>
.
|
@ic4f I'm sure this is an easy one for you, what did we need to do for this unit test failure?
|
I'm looking into this - give me a few minutes :-) |
@hexylena You need to add the following to this dict: https://github.com/galaxyproject/galaxy/blob/release_20.09/test/unit/config/test_config_values.py#L100
It tells the test how to prepare the expected value: it places the 'EDAM.tsv' file inside the Sorry for the lacking docs (it's all in the comments in that test file). |
thanks @ic4f
@mvdbeek Yeah, no opposition here; my comments earlier were just thinking forward to future iterations :) |
The test could maybe tell us that, so if it fails we know what to do ? |
@mvdbeek yes (a message can be passed to the test with the rest of the data for cases where such a message makes sense). However, the path generation for the test can be automated: we have the key, we have the schema which contains the |
part of #10587. This was honestly pretty easy and it looks great? (Minus the hundreds of unannotated tools.)
Original Notes
I just took the existing ITP loading code and replaced it with edam generated topics rather than whatever section they requested.
Sorting based on EDAM would be nice (edit: done!) E.g. the following image:
Bugs:
we have a copy of the EDAM ontology in the codebase. Surely there's a better way to handle this?All the tests fail, even though I made this opt-in?Sorting based on EDAM ordering would probably be better.