(fix): resolve data ordering to match axis for stacked violin plots

[ilan-gold]

• Closes Incorrect column label and color assign when using 'rank_genes_groups_stacked_violin' with 'swap_axes=True' #3152
• Tests included or not required because:

• Release notes not necessary because:

[ilan-gold]

Will finish after lunch....wowza

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 74.12%. Comparing base (bb66827) to head (f5ea470).

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #3196      +/-   ##
==========================================
- Coverage   76.61%   74.12%   -2.50%     
==========================================
  Files         109      109              
  Lines       12532    12497      -35     
==========================================
- Hits         9602     9263     -339     
- Misses       2930     3234     +304     

Files	Coverage Δ
src/scanpy/plotting/_stacked_violin.py	84.07% <100.00%> (-0.43%)	⬇️

... and 30 files with indirect coverage changes

[ilan-gold]

Not exactly sure how to test this - it's not that the axis is misordered, it's that we were not informing the violin plot of this ordering. I am not sure if there is a way to access the underlying data of a plot...

[flying-sheep]

I have some limited experience with that plot order stuff.

There’s some compat code for old pandas versions added in #2816 which shows some spots where we mess with ordering.

Generally

• when user specifies an order, we use that
• if not, we rely on the DataFrame order for plotting, we don’t store this implicit order explicitly

[ilan-gold]

@flying-sheep I think the code added in that PR is minimally relevant to what happened here.

when user specifies an order, we use that

Right, so here the issue is that the category ordering is used for the labelling but we were not imposing it on the data itself when the violin plots render (separate from the axis labels, as the actual violin plots are added row-by-row).

if not, we rely on the DataFrame order for plotting, we don’t store this implicit order explicitly

In some sense the above also applies. If we want to add some sort of user-facing part of the API to allow for ordering, that is fine, but I think that should be separate as it would go into the next minor release and this is a fairly large bug.

I'm fine not testing this because I genuinely don't know how and I spent a few hours yesterday trying different things to no avail.

[flying-sheep]

I trust you that this helps 🤷

[ilan-gold]

I trust you that this helps 🤷

I guess we can add a test that cements this behavior, but it's tough to test that swap=original-transpose for the underlying data. I tried applying the ordering to what changed in the PR you referenced but that didn't help unfortunately. I don't know the provenance of that change, so I think this is fair. We are using the public API of seaborn in a way that fixes the underlying issue as one would expect.