Up to you, if you are confident the merge is fine you can push directly, but a PR doesn't hurt.
there is a tiny change I need to make. It'll work without it. The change is an edit to 1 line and changes "works" to "always works and is correct as per docs". This is a separate commit. Can I submit it with the merge in the same PR? Or would it be more convenient to have 2 separate PRs?
Put it in the PR, no point for the separate PRs. If you need to target 21.09 with the fix you can start with that
OK, thanks
Note this is only (if I understand correctly) the fork, and not the one maintained by Sylabs (SingularityCE). Although I honestly don't quite understand the distinction between the two.
Even their citing section doesn't really clear it up: https://github.com/apptainer/singularity
Not much to my understanding.
So if nothing else, the name change is very helpful!
@davebx: I just tried allowlisting a tool on Main and ran into some issues: The latest version seems not to appear in "HTML Sanitized", 2 of the 3 tool IDs had their versions mangled in the allowlist file (they had a space in the version number where the
+ should be):toolshed.g2.bx.psu.edu/repos/iuc/snpfreqplot/snpfreqplot/1.0 galaxy1
toolshed.g2.bx.psu.edu/repos/iuc/snpfreqplot/snpfreqplot/1.0 galaxy2
toolshed.g2.bx.psu.edu/repos/iuc/snpfreqplot/snpfreqplot/1.0+galaxy0
or forgot to handle spaces
Not sure how those request params are handled but a urlescaped space is a +
1 reply
Curious it worked for one but not others though, that sort of heisenbug will surely be fun to track down. ;D
I'm thinking of complex tool forms created from biom datasets, better the contained metadata: Lets say we have metadata
- location: with values skin and gut
- day: 1, 2, 3 ...
Then I want to generate a tool that allows to select the metadata (location/day) and in a second select the corresponding values
Currently this seems not possible. First of all the Biom1 class does not store metadata values. But also on the tool side I'm not sure if this can be realized.
1 reply
I also thought about just using the tabular metadata (which we could extract from the biom file. Then this would correspond to choose a column in the first select and then we would need to choose from the values in this column in the second... but I can't think of a way to address the column in the 2nd select
Anyone knows if this could be possible from the tool side? ..
that's from https://github.com/galaxyproject/galaxy/blob/dev/test/functional/tools/options_from_metadata_file.xml ... although
meta_file_key references an actual file, but referencing lists or other iterables should also be possible
(
should as in shouldn't be hard to implement, given that meta_file_key seems harder to do than something like meta_element that refers to a MetadataElement on the dataype)
I'm somewhat surprised we don't seem to have this ... why do we even collect all these metadata elements if you can't build an interface from it
If you want to give it a shot, you could add another elif in https://github.com/mvdbeek/galaxy/blob/08d7bb730ce231759beefae872ab212e5ea4cd71/lib/galaxy/tools/parameters/dynamic_options.py#L678 to pick the options from
dataset.metadata[meta_element]
Can some one tell me why the new test tool (filter_param_value.xml) added here galaxyproject/galaxy#13039 is not running in the framework tests .. guess again some problem on my side :(
Apparently not, its not listed in the output of the framework test.
If I test it manually with
planemo test then there is a tool load error because of the forward reference in the param_value filter of the first select... but I would expect that the tool is still included in the tests and the error shows up there ... ?
That would be nice, but also tricky to know what tool load error should be a failure