A variety of improvements around tool parameter modeling (second try) #19027
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
2 tasks
bgruening
reviewed
Oct 18, 2024
| self.datalist = [] | ||
| for title, value, _ in input_source.parse_static_options(): | ||
| self.datalist.append({"label": title, "value": value}) | ||
|
|
||
| # why does Integer and Float subclass this :_( |
There was a problem hiding this comment.
I don't know but the code sharing in this file is very problematic all over.
| ): | ||
| super().__init__(message, negate) | ||
| assert filename | ||
| assert os.path.exists(filename), f"File {filename} specified by the 'filename' attribute not found" |
There was a problem hiding this comment.
Is that really needed here as assert?
There was a problem hiding this comment.
It was present in the existing validation code. I guess the idea is to not load the tool if that file is not available.
| self._inputs = inputs | ||
| return self | ||
|
|
||
| # aliases for self to create silly little English sentense... inputs.when.flat().when.legacy() |
jmchilton
force-pushed
the
parameter_model_enhancements
branch
from
0a01326 to
bf2f290
Compare
jmchilton
force-pushed
the
parameter_model_enhancements
branch
from
bf2f290 to
e053eee
Compare
2 tasks
bgruening
approved these changes
Oct 28, 2024
Suspect IssuesThis pull request was deployed and Sentry observed the following issues:
Did you find this useful? React with a 👍 or 👎 |
jmchilton
added a commit
to jmchilton/galaxy
that referenced
this pull request
Oct 31, 2024
- Allow specifying a min/max for integer and float parameters. - Swap language from regex to "Regular Expression" and synchronize help with regular expression fields in rule builder. - Extend regular expression help. - Improve default message for in_range validator. Probably a reversion in some ways introduced with galaxyproject#19027.
2 tasks
jmchilton
added a commit
to jmchilton/galaxy
that referenced
this pull request
Oct 31, 2024
- Allow specifying a min/max for integer and float parameters. - Swap language from regex to "Regular Expression" and synchronize help with regular expression fields in rule builder. - Extend regular expression help. - Improve default message for in_range validator. Probably a reversion in some ways introduced with galaxyproject#19027.
jmchilton
added a commit
to jmchilton/galaxy
that referenced
this pull request
Nov 4, 2024
- Allow specifying a min/max for integer and float parameters. - Swap language from regex to "Regular Expression" and synchronize help with regular expression fields in rule builder. - Extend regular expression help. - Improve default message for in_range validator. Probably a reversion in some ways introduced with galaxyproject#19027.
jmchilton
added a commit
to jmchilton/galaxy
that referenced
this pull request
Nov 7, 2024
- Allow specifying a min/max for integer and float parameters. - Swap language from regex to "Regular Expression" and synchronize help with regular expression fields in rule builder. - Extend regular expression help. - Improve default message for in_range validator. Probably a reversion in some ways introduced with galaxyproject#19027.
jmchilton
added a commit
to jmchilton/galaxy
that referenced
this pull request
Nov 8, 2024
- Allow specifying a min/max for integer and float parameters. - Swap language from regex to "Regular Expression" and synchronize help with regular expression fields in rule builder. - Extend regular expression help. - Improve default message for in_range validator. Probably a reversion in some ways introduced with galaxyproject#19027.
jmchilton
added a commit
to jmchilton/galaxy
that referenced
this pull request
Nov 13, 2024
- Allow specifying a min/max for integer and float parameters. - Swap language from regex to "Regular Expression" and synchronize help with regular expression fields in rule builder. - Extend regular expression help. - Improve default message for in_range validator. Probably a reversion in some ways introduced with galaxyproject#19027.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
A redo of #18952 on top of the new tool execution testing stuff and with a few more fixes.
Old PR Description:
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)
License