Open mvdbeek opened 5 years ago
- A sustainable and reliable way to make collection out of a zipped input would be great!
For me its often the automatic naming of data sets, which mainly comes from the fact that with multiple="true"
collections are not treated as collections but as a bag of data sets. Take for instance the following history that I created in the (short) mothur tutorial from the GTN.
Here the list 168 sub.sample shared has been the chosen as input to 179 collapse collection, but the name of the data set says Collapse collection on data set 171
which is hidden in the history. So the connection of the steps is obfuscated.
This has been raised here:
https://github.com/galaxyproject/galaxy/issues/7467 https://github.com/galaxyproject/galaxy/issues/7392
Problems are at least documented now:
https://github.com/galaxyproject/planemo/pull/930
In addition I don't see a way to find out which data sets are contained in a collection. For instance the single member of 179 has the name "0.03", which is data set 171. If this data set number would be shown in the collection display the connection would be clear(er).
But for sure collections are a good step in the right direction. The alternative of having a flat history with no structure (apart from the linear structure corresponding to creation time).
Maybe collections just should be used more -- in particular nested collections. For instance, the output of each tool could be a collection containing all the other outputs. The tools of the stacks suite do something in this direction, but without nesting. On the other hand the user then needs to click more to get to the desired information.
At the moment, it seems collections are primarily for grouping inputs and outputs vis a vis a mapped workflow situation. I am more interested in using collections to group outputs together for easy download as a single unit. Currently, it doesn't seem like you can apply data filters to elements of a collection (as opposed to the whole collection itself), which makes sense for a mapped workflow situation, but not so much for simply grouping outputs. Also, the documentation on filtering output collections vs output data appears to have mistakenly duplicated the docs for filtering data outputs only.
Some UX bugs during my trawl through old issues, mostly around "missing the standard edit/view/bug icons of normal datasets"
Not being able to change the datatype for all datasets in a collection. It's not even possible to write a script with the API, which would be an acceptable second option. This is just torture, please focus on fixing these bread-and-butter issues because it really affects usability.
Downloading all files in a collection (can be done with bioblend).
Downloading all files in a collection (can be done with bioblend).
This is already possible in the web UI. Open the collection. Then you see a little download symbol at the top.
Thanks @bernt-matthias, you are right. I wish it was more visible, though.
Collections cannot be published in the same way that datasets can. Published datasets can be downloaded via /datasets/{id}/download
; this doesn't work for collections.
(The download button mentioned in the comments above points to /api/dataset_collections/{id}/download
(/api/histories/{hid}/contents/dataset_collections/{id}/download
seems to work fine too) but these require API authentication so are not helpful. Yes, you can probably log in, import the history and download, but IMO 'public' means 'available to everyone, not just people with Galaxy accounts'.)
If I missed something here, please let me know, it would be very helpful.
I would like to see wider adoption of collections among Galaxy users, and I'm trying to understand how we can improve collections (or the documentation surrounding collections) to reach that goal. So if you've tried them recently and were stuck at any point and felt that going back to regular datasets was the better option please let us know!