YTEP-0040: a yt-baked colormap package


Created: 20 April, 2021 (happy 40th birthday Matt !) Author: Clément Robert

I propose to extract native colormaps (“cmaps” hereafter) from yt into a separate, lightweight package.



Detailed Description

An undocumented behaviour change in Matplotlib 3.4.0 made naming collisions in cmaps fatal. Registering a new cmap with a previously registered name will not work any more, and cause the program to crash. Up to yt 3.6, we’ve been automatically registering cmaps from various sources. Most notably: - yt itself - IDL - cmocean

All of the cmaps in questions are (or used to be) registered with bare names, i.e. without a dedicated prefix. This means that if any of our cmaps’ names is used in the future release of Matplotlib, importing yt will fail with a ValueError.

Good practice is in fact to register cmaps under a custom “namespace” (prefix) that is guaranted to never collide with matplotlib native colormpas. This is what is currently done in cmocean itself (prefixing with "cmo.") as well as, for instance cmasher (prefixing with "cmr.").

Since migrating away from the fragile current registration method requires a structural change anyway, I propose we seize the opportunity to make yt native cmaps easier to use from outside the framework (to footnote: it is actually already doable but it requires loading the entire package) and export them into a small, lightweight, easy to maintain and install package.

Such a package would be a hard dependency of yt itself.

In case this proposal is accepted, the exact prefix used is up for discussion. I can propose 1) cmy. pros: perfectly fits the dominant convention, cons: doesn’t look like yt 1) yt. pros: dead simple, best at “brand” reinforcement, cons: doesn’t align with the dominant convention 1) cmyt. pros: has “yt” _and_ “cm” in the name, cons: one char more that the dominant convention

My personal preference goes to cmyt., and I’m going with it as the proposed package name in the following.

NOTE: the fate of IDL orignated colormaps currently registered and vendored by yt is not clear. They could be ported as yet another package (and maybe made a hard dep to yt too ?), or be included in the first package (not my favourite option).

Backwards Compatibility

Forcing people to add prefixes everywhere is not (yet ?) necessary, but the practice should be encouraged nevertheless. One way to bridge the gap between current “malpractice” and a more stable usage in yt would be to perfom reregistrations of cmyt’s cmaps without a prefix (similarly to what was previously done with cmocean, though in an error-safe way).

Maybe this could be done silently in yt 4.0 (to save our users as much of a migration burden as possible), then raise visible deprecation warnings starting from yt 4.1, and finally be completely deprecated in yt 4.2 or yt 4.3 .


  • Perform structural changes in how yt registers its own cmaps (necessary) without making

the result a new package (not necessary, but offers some additional benefits).

  • Perform the necessary changes on yt side, export the cmaps into a separate package but keep them in the main package too (code duplication, not my cup of tea).