Append means take a collection type and extend it by the current type - so appending to list to paired -> list:paired for instance. ANY_COLLECTION_TYPE is a representation of incomplete information - it means this type description might be any kind of collection type (the way we use "input" to mean any kind of datatype in the editor).
This is really a second order approximation of what a correct solution would be - a first order approximation would somehow represent the result of append being at least of "depth" specified (list:* or *:list instead of * for instance). A not approximation would be to do that but use ANY_COLLECTION_TYPE much less frequently by capturing type_source information and propagating it throughout the workflow properly. But these are harder things to do, this incorrect fix will allow many valid workflows to be editted that currently cannot be so I think it is good.
"Fixes" #5205.
serving at least in the multiview, and I'm not seeing errors elsewhere
(yet). We should look at other urlRoot usage though; it likely has
issues.
This reverts commit 62811d0a40aafe5db8c5121ff857788c59880b56.
- Require a URL or FTP column for raw pasted data.
- Require list identifiers if creating collections.
- Require name in more scenerios that require a name.
A mistake was made in the rush to rule-builder-all-the-stuffs - libraries, hdas, and FTP all initialized a different set of columns from the data (which is probably fine) but with no indication this was happening in the underlying rules (which is definitely not fine).
To understand why this was a mistake and see why in the long term this hurts reproducibility, take loading rules for HDAs from the history panel as an example. In the initial implementation it would pre-initialize two columns - one for "hid" and one for "name" - any rules that were generated from there would start with an implicit assumption of two columns. This is a problem because if someone saves some rules and we (Galaxy developers) decide later on that name tag should be in the initial list but HID doesn't make sense and make that change - we basically are breaking all existing rules to support a very logical change in behavior. Likewise, Galaxy produces a hash with last modified date and size for each FTP entry - this is data we have and could stick in the rule builder by default - but if we change that over time existing FTP rules will break.
It would be much more sustainable to instead include the initial column generation information in the initial rules generated - so that each of these modalities start in reality with an empty table and the initial set of rules describe what metadata to pull initial columns from. This way if you save a set of rules it will include the initial column choices, and if they are pasted in at some later point where columns are picked differently - the rules will still work because you are replacing the initial column definitions.
The initial rules implementation didn't have this concept of loading columns from metadata - but this was added to support loading existing identifiers as part of the "Apply Rules to Existing Collection" tool. This commit extends that idea to do the same thing (but with different columns) when loading data from HDAs, FTP, and data libraries.
Present users with the job standard error and also check for binary sniffing problems and report them with a pretty message suggesting specifying a file type.
John Chilton