Badge request: galaxy-toolshed

[guillaume-gricourt]

:clipboard: Description

This badge is dedicated to Galaxy Toolshed. People could have the version of their tools in their repositories. Like: galaxy-toolshed|v1.0.0 In repository of Galaxy Toolshed, you have a repository (identified by a name and an owner) with one or several tools (with a name and a version). Each tool could have one or several requirements and each has a name and a version. It would be useful to grab version of a tool available in a repository and the version of a requirement corresponding to a tool.

:link: Data

• Is there a public API? yes
• Does the API requires an API key? no
• Link to the API documentation. API

:microphone: Motivation

The specific use case: show the badge in Github repository. During a continuous deployment, you want to check the version of a tool in:

• github: version badge available
• conda: version badge available
• galaxy-toolshed: version badge not available <- the need

Suggest PR #7633

[calebcartwright]

Shifting discussion over here vs. the PR for now.

Could you please elaborate on the specific badges you are proposing, and do so individually? The motivation field in our issue template is primarily about conveying information about the service and the underlying data points, which is especially important given the hundreds of platforms/services Shields integrates with (the majority of which are not tools we as maintainers actually use/are necessarily familiar with). We're already very aware that folks can and do put our badges in places like readme files :wink:

In particular, it would be really helpful if you could provide an overview of what Galaxy Toolshed is, how it's used, who the primary audience/users are. It would then be helpful to enumerate the badges that you'd like to see, which we can then use to have a more structured conversation around implementation in your PR

[guillaume-gricourt]

Yes, let me talk about the Galaxy Project:

Galaxy is an open-source platform for FAIR data analysis that enables users to:

• use tools from various domains (that can be plugged into workflows) through its graphical web interface.
• run code in interactive environments (RStudio, Jupyter...) along with other tools or workflows.
• manage data by sharing and publishing results, workflows, and visualizations.
• ensure reproducibility by capturing the necessary information to repeat and understand data analyses. The Galaxy Community is actively involved in helping the ecosystem improve and sharing scientific discoveries.

So, one of Galaxy's features runs tools through a web interface. From 2005 to 2021, 11686 scientific papers have cited the Galaxy project. The tools (about 8591, Feb 2021), freely available to use by the community, are store in the Galaxy toolshed. People could host their own Galaxy Toolshed. But the main toolshed is widely used and is the reference among the community. This suggested service requests only on the main toolshed. Informations about the tools stored in the main toolshed could be requested with its API. Several kinds of request could be made from this API:

• version of tools
• popularity (number of downloads)
• ...

I think the main information to get from this API is the version of a tool. A repository could have different versions (history), contains one or more tool and each tool could have one or more tools required to work. So, I suggested two features:

• get the version of a tool: repository name, owner id and tool id are required
• get the version of a one or several requirement of a tool: repository name, owner id, tool id and requirement name are required
• get the version of repository is not implemented: it's a hash automatically generated and, I guess, it's not necessary.

So, the schema of the route is (inspired from debian): :repositoryName/:owner/:toolId/:requirementName? If you want all requirements of a tool, you type all in place of requirementNameto grab all of requirements, rendering is inspired from clojars service. And, to be more precise, a parameter display adds, with three keywords repositoryName, toolId, toolName, the corresponding value of the request to the default value galaxy-toolshed.

[guillaume-gricourt]

What do you think about this description ? How should I improve this PR #7633 ?

[calebcartwright]

I appreciate the extra information. It's somewhat helpful, though I still feel like you're more focused on the implementation details as opposed to the motivation. We don't typically add a badge just for the sake of adding one/because it's possible, so I'd still like to understand the "why" aspect from my prior comment. To elaborate on what I mean:

I think the main information to get from this API is the version of a tool.

The motivation for this is straightforward. A tool author would leverage this badge to convey to their consumers what the latest published version of their tool is.

popularity (number of downloads)

This one is also a straightforward motivation and usage pattern, although it doesn't seem to be in scope/part of the PR.

get the version of a one or several requirement of a tool: repository name, owner id, tool id and requirement name are required

However, this one is still ambiguous and is essentially describing the process of fetching data as opposed to why a tool author would want to use such a badge and/or what significance it would carry to tool consumers.

Could you elaborate on this particular use case and in what context one might want to display the version of a requirement of a galaxy tool?

We support this type of badge for a few services, but those don't really exist just for purposes of trivia. They are provided in ecosystems that tend to have larger dependency trees that can end up having some interference/implications.

e.g. a package maintainer may want to convey that version 1 of their package has a reliance on v3 of dependency Foo to their consumers. In some more uncommon cases that's useful information to consumers because they may also directly consume some version of Foo or they may transitively depend on Foo due to other packages which use different versions of Foo.

My sense is that pattern wouldn't really exist in this ecosystem, but please feel free to expand on the use case for this within the galaxy context.

[guillaume-gricourt]

Thank you for your comment. Concerning the popularity feature:

it doesn't seem to be in scope/part of the PR.

You're right, I will add it in the PR, corresponding to the Downloads section. Moreover, I will add the release date to fit into the Activity section. I will try to bring a more precise picture of the use cases for the badge version.

• First case, I agree, the end user wants only the version of the repository
• Second case, a developer has repository, a his repository package is used (like several others) in several tools inside one repository available in the Galaxy Toolshed. Ok, he's happy to see his tool used by others and he wants to track the versions of his package (it could be different) in the different tools in one repository from the Galaxy Toolshed.

It's quite the same principle as conda version's tracking. If you have one tool in the repository Toolshed with one package (the version that you want to track), and the version of the package follows the version of the repository Galaxy ToolShed: it's the same as conda. But, if you have more than one tool, more than one package or the version of the package (that you want to track) doesn't follow the version of the repository, if you don't add these features, you couldn't track the version of the package used in the repository. Let me know if my explanation is always unclear.

[calebcartwright]

Second case, a developer has repository, a his repository package is used (like several others) in several tools inside one repository available in the Galaxy Toolshed. Ok, he's happy to see his tool used by others and he wants to track the versions of his package (it could be different) in the different tools in one repository from the Galaxy Toolshed.

While that personally strikes me as a bit of a stretch, I do think that's a reasonable enough of a use case :+1: However, this would need to be changed in order to only show the version of a single dependency. I'd definitely be opposed to trying to have a single badge that displays an unbounded collection of dependency+version pairs, both for reasons of consistency with our other badge and for general aesthetics relative to our badge specification that guides our defaults (too noisy/verbose)

i.e. something more like this instead:

etc.

[guillaume-gricourt]

That's great ! I will amend the code.

[guillaume-gricourt]

I've added and modified the code for these 3 topics:

• version: simplify the display as suggested
• download: print the number of downloads
• activity: get the date of creation for the repository

Now, the code should be respect your specifications.

[guillaume-gricourt]

@calebcartwright in response to https://github.com/badges/shields/issues/8249#issuecomment-1207126783 I have modified the code to have a message with the same behavior as the other services (https://github.com/badges/shields/issues/7660#issuecomment-1079980469) Repository version
Pattern: galaxytoolshed/v/:repository/:owner
Display: Why?: I think this badge will be the less useful, the developer didn't choose this version
Tool version
Pattern: galaxytoolshed/v/:repository/:owner/:tool
Display: Why?: this badge will display the version of a target tool, coming from a github repostory Requirement version
Pattern: galaxytoolshed/v/:repository/:owner/:tool/:requirement
Display: Why?: this badge will display the version of a dependency from a target tool, coming from a github repostory.

Rendering the tool and requirement versions seems to be a valuable feature.

[calebcartwright]

Thanks @guillaume-gricourt. I want to make sure I understand the structure of the system and I'm not 100% I do

Let me know if the following is accurate:

• The Galaxy Toolshed service/platform has top level organizational units called "Repository"
• A Repository itself is versioned, and a Repository can contain one or more "Tools"
• A Tool itself is versioned, and versioned independently of a Repository
• A Tool can also have one or more "Requirements", and Requirements are themselves versioned independently

[guillaume-gricourt]

Yeah, it's right. If we can show the version of each layer (repository, tool and requirement) it would be very helpful.

[guillaume-gricourt]

Hi @calebcartwright What can I do for the PR #8249 ?

[PyvesB]

@calebcartwright shall we try to get this landed? Anything we can do to help?

[PyvesB]

The new version badges have successfully been shipped to production, closing this issue!