but we don’t have the UI and we need dataset hashes to make this really efficient and useful
:D
@jmchilton here are a few examples:
ctd/CVInspector.ctd: <ITEMLIST name="ignore_cv" type="string" description="A list of CV identifiers
which should be ignored." required="false" advanced="false">
ctd/CVInspector.ctd: <LISTITEM value="UO"/>
ctd/CVInspector.ctd: <LISTITEM value="PATO"/>
ctd/CVInspector.ctd: <LISTITEM value="BTO"/>
ctd/CVInspector.ctd: </ITEMLIST><ITEMLIST name="target_modifications" type="string" description="List the amino acids to be searched for and their mass modifications, specified using UniMod (www.unimod.org) terms, e.g. 'Carbamidomethyl (C)'" required="false" advanced="false" restrictions="15N-oxobutanoic (N-term C),2-dimethylsuccinyl (C),2-monomethylsuccinyl (C),2-nitrobenzyl (Y),2-succinyl (C),2HPG (R),3-deoxyglucosone (R),3-phosphoglyceryl (K),3sulfo (N-term),4-ONE (C),4-ONE (H),4-ONE (K),4-ONE+Delta:H(-2)O(-1) (C),4-ONE+Delta:H(-2)O(-1) (H),4-ONE+Delta:H(-2)O(-1) (K),4AcAllylGal (C),a-type-ion (C-term),AccQTag (K),AccQTag (N-term),Acetyl (C),Acetyl (H),Acetyl (K),Acetyl (N-term),Acetyl (S),Acetyl (T),Acetyl (Y),Acetyl:13C(2) (K),Acetyl:2H(3) (H),Acetyl:2H(3) (K),Acetyl:2H(3) (N-term),Acetyl:2H(3)...">
<LISTITEM value="Phospho (S)"/>
<LISTITEM value="Phospho (T)"/>
<LISTITEM value="Phospho (Y)"/>
</ITEMLIST>Since both cases don't have restrictions we can't render them as <select> and repeats don't work, because I can't set the defaults.
My favorite solution would be a select where the user can add values.
The repeat units are very simple here, i.e. single string (but can be int,float as well)
@nsoranzo : btw:
<param><value></value></param> does not work in a test :(
:D
damn, this is probably bad news: https://travis-ci.org/galaxyproject/tools-iuc/jobs/620630685?utm_medium=notification&utm_source=github_status
Unexpected HTTP status code: 500: {"err_msg": "Error attempting to parse file tool_data_table_conf.xml.sample: Merging tabular data tables with non matching columns is not allowed: twobit:{'path': 1, 'name': 0, 'value': 0} != twobit:{'value': 1, 'dbkey': 0, 'name': 1}"}
probably a good check, but kind of surprising
there is a mismatch in the colum definition in extract_genomic_dna and the data manager
I suppose the data manager one should win
Since 2015, commit galaxyproject/galaxy@30f1815
I’ll open a PR, let’s see if it gets in
Is this for the container tests? I remember that in the first iteration there was only one failing emboss tool which I tried to fix here galaxyproject/tools-iuc#2725.
that was emboss 5 only
The linter seems broken though,
should_not_be_noarch_source when there is no noarch makes no sense
to both
Question, I added a new version of a tool to bioconda-recipes. I'd like my galaxy wrapper to use that new version (no interface changes to the wrapper - just a bug fix). I updated the version attribute of the requirement tag in the wrapper's xml, but when I run
planemo serve, it's still using the older version. What change must I make to have it use the newer bioconda-recipes version? (Note, if I do conda install toolname on the command line, it installs the new version.)
Hmmm. It's is still using version
2.006 instead of 2.0013. I think I probably need to bump the wrapper version. I was using some weird version spec and I see that the latest spec says that the <tool version attribute should be tool_version+wrapper_version. I only had wrapper_version.
Sure, although I accidentally got it to run the new version - and I'm not sure why it worked. I accidentally ran
planemo serve from the main tool repo directory instead of the specific tool directory and it happened to use the new version when I ran it. Now if I run it from either, it uses the new version. I don't understand it. https://github.com/hepcat72/robs_galaxy_tools/tree/vcfsc13/tools/vcfsamplecompare
glad it works now