[Feature Request] Export methods (tool versions/params) for workflow/history

[hexylena]

The export citations feature is fantastic. Could a similar report be generated with:

• These tools were run
• These versions
• These parameters

for assisting in writing the methods sections of papers? (I know I can script this, but, this should be one click)

[hexylena]

I am returning to this issue as I now need to do it, and finding Galaxy's nomenclature choices causing a fair bit of work, and I'm not sure how to solve the issue.

Here is the correspondence I'm currently looking at:

Galaxy Tool Line	What I think I should be writing in my methods
Faster Download and Extract Reads in FASTQ format from NCBI SRA (Galaxy Version 3.0.8+galaxy1)	fasterq-dump (SRA Toolkit Release v3.0.8)⁰
FastQC Read Quality reports (Galaxy Version 0.74+galaxy0)	FastQC (v0.74)
Cutadapt Remove adapter sequences from FASTQ/FASTA (Galaxy Version 4.4+galaxy0)	Cutadapt (v4.4)
HISAT2 A fast and sensitive alignment program (Galaxy Version 2.2.1+galaxy1)	HISAT2 (v2.2.1)
Read Distribution calculates how mapped reads were distributed over genome feature (Galaxy Version 5.0.1+galaxy2)	read_distribution.py (RSeQC v5.0.1)
Column join on multiple datasets (Galaxy Version 0.0.3)	join (GNU Coreutils 8.25)
Sort data in ascending or descending order (Galaxy Version 1.1.1)	sort (GNU Coreutils 8.25)
annotateMyIDs annotate a generic set of identifiers (Galaxy Version 3.16.0+galaxy1)	annotateMyIDs.R¹ a script using org.hs.eg.db² (Bioconductor release 3.16³)

⁰ this does feel vaguely like 'erasing' the +galaxy# contributions, but those also generally aren't relevant for the methods that I'm writing up. so 🤷‍♀️ I need to focus on the analytical steps? Also I can see an argument for not mentioning the coreutils, but the rest should be there.
¹ this is also a strange thing, there's an original github repo with a .R version, but this has been migrated into the tool XML so it's a bit synthetic to say, but it's also the annotation that makes the most sense?
² here it's the only database that was actually used which makes me afraid it should be a string calculated at runtime, but maybe we can relegate this to an edge case and not concern ourselves with it
³ note the lack of a 0, bioc lacks a patch version, that's a conda invention!

I start to wonder if we need to record this information in a different field? Annotating the toolkit something came from is really non-standard (e.g. sra toolkit vs emboss vs others), and the name of the tool within the toolkit we don't always use because sometimes it's not very human friendly in the case of fasterq-dump.

Perhaps in the citations section as a <citation type="methods">fasterq-dump (SRA Toolkit Release v@TOOL_VERSION@)</citation> for something dead simple (trusting the tool author to fill it properly) or in the xrefs or something to collect "underlying tool name" and "toolkit/suite name", from which we could construct the above?

I think the "Galaxy Version" nomenclature is also quite strange, it's a galaxy wrapper yes, but now that we've standardised on +galaxy for Galaxy specific changes to a tool, I think I (personally) would much, much rather see it written like "FastQC Read Quality Reports (Version 0.74, Galaxy rev. 0)" separating out the tool version from the galaxy changes somehow (but this is my opinion and might not be popular.)

---

unrelated but https://usegalaxy.eu/root?tool_id=toolshed.g2.bx.psu.edu/repos/iuc/limma_voom/limma_voom/3.50.1+galaxy0 doesn't seem to render the first citation on EU, .org is fine, I'm not sure why. Unfortunate.