Skip to content
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

A variety of improvements around tool parameter modeling. #18952

Closed

Conversation

jmchilton
Copy link
Member

This contains tests, fixes, and refactorings of the tool parameter models aimed at enabling two applications/APIs - these applications are a tool landing API and the tool request API. Those APIs and corresponding runtimes are not included here but can be found in the structured tool state branch (tool request API and tool landing API).

The bulk of the enhancements around enabling tool landing are found in a single commit titled "models for tool landing request state...". This introduces two new tool state representation types and wide variety of parameter specification tests that describe how the API will work and how models will be stored. The API will consume tool state with the representation type "landing_request" and will store the representation "landing_request_internal" in the database. The internal version is the decoded version of that tool state. The idea behind the landing API is that essentially everything is optional - external entities could for instance host a collection of FASTA files and provide links to tools to align against these for instance - all the parameters but the database would be deferred to the users discretion. The parameters that are provided though will be validated.

The remainder of the commits are a collection of things that make more confident were not doing damage with the tool request API. Part of that effort is having a fully expanded representation of the tool state that describes something pretty close to what we feed the wrappers - defaults expanded out, no absent conditionals, etc... That effort resulting in me writing lots of API tests to describe how the current API works so we don't regress it, implementing validation of static parameter validators so we can mimic some of the runtime behavior of the tools and write stronger upfront validation of the requests, etc...

How to test the changes?

(Select all options that apply)

  • I've included appropriate automated tests.
  • This is a refactoring of components with existing test coverage.

License

  • I agree to license these and all my past contributions to the core galaxy codebase under the MIT license.

@jmchilton jmchilton added kind/bug kind/enhancement kind/refactoring cleanup or refactoring of existing code, no functional changes area/API area/tool-framework labels Oct 8, 2024
@jmchilton jmchilton force-pushed the parameter_model_enhancements branch 6 times, most recently from 2c8ff78 to 006d643 Compare October 9, 2024 12:23
@jmchilton
Copy link
Member Author

I'm closing this out - I'll rebase it on #18977 and reopen a new version of this. That will clean up things nicely I think.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
area/API area/tool-framework kind/bug kind/enhancement kind/refactoring cleanup or refactoring of existing code, no functional changes
Projects
None yet
Development

Successfully merging this pull request may close these issues.

1 participant