About the header of the custom table in tsv

[kk1120]

I am now creating a custom table with the tsv file as input.
The inputs are as follows...

# plot_type: 'table'
# section_name: 'DADA2'
# pconfig:
#     namespace: 'Cust Data'
# headers:
#     col1:
#         title: 'Input'
#     col2:
#         title: 'Filtered'
#     col3:
#         title: '% Pass Filter'
#         suffix: "%"
#     col4:
#         title: 'Denoised'
#     col5:
#         title: 'Non Chimeric'
#     col6:
#         title: '% Non Chimeric'
#         suffix: "%"
Sample Name	col1	col2	col3	col4	col5	col6
ABC002	76394	71256	93.27	70831	70131	91.8
ABC004	63611	59126	92.95	58607	57830	90.91
ABC006	59750	56527	94.61	55906	54877	91.84
ABC007	55976	52499	93.79	51992	51680	92.33
ABC009	41547	37639	90.59	37335	37002	89.06
ABC010	34570	32657	94.47	32258	31917	92.33
ABC012	49106	45668	93	45219	44127	89.86

However, it seems that the columns are sorted by the name of the header title.
I want to keep the original header order
Sample Name Input Filtered % Pass Filter Denoised Non Chimeric % Non Chimeric
How can I do this?

[ewels]

Hi @kk1120,

Thanks for reporting this. I just came across the same problem myself.

This appears to be a current limitation of MultiQC - that is, it's not possible to keep them sorted at the moment. It's a bug that needs fixing.

Looking back at the code, the reason basically comes down to the fact that this code was written for Python 2, pre- custom content. Headers in modules always use OrderedDict() to specify the order of table columns, as in Python 2 dictionary keys are unordered. Because in Python 2 the order would be random if not an OrderedDict, the code sorts the keys alphabetically if it's a vanilla dict, just so that the order is at least predictable and doesn't shuffle every time you run MultiQC.

The problem with custom content is that the header config is loaded from YAML, and it's not possible to import as an OrderedDict. However, MultiQC is Python 3.7+ only now, so we don't need any of this stuff any more 😓

I'll try to push a short-term fix to dev now, but longer term the codebase needs refactoring to get rid of this Python 2 junk that we don't need any more. x-ref #1919

Phil

[ewels]

Fixed in dev - now behaves as you'd expect.

[kk1120]

Hi! Thank you very much. It went well.