I vaguely remember a discussion around the fact that this was exposed in a "public" way, and therefore should be removed with a deprecation cycle.

That's my memory as well.

[six] should be removed with a deprecation cycle.

You are right, there is actually a deprecation warning already raised on top of six, so it should be removed in 0.23.

Reverted that change and now this only removes a couple left-over six imports. Surprising that tests didn't fail on deprecation warnings there BTW.

We've decided to deprecate externals.six, see #12916
We won't get a deprecation warning here because we import from six, not externals.six.

We won't get a deprecation warning here because we import from six, not externals.six.

Indeed. Why is it not failing then? six should not be in the list of dependencies (unless it's indirectly pulled by one of our dependencies).

Indeed. Why is it not failing then? six should not be in the list of dependencies (unless it's indirectly pulled by one of our dependencies).

I don't know, we need someone who is familiar with our CI :)
(but I guess you're right, i.e., six is installed by other packages, or by default)