Deprecate the `"default"` colorscale name and `list_all_colorscale_names()`

[tpvasconcelos]

The only reason we still need list_all_colorscale_names() is because we decided to add an extra "default" named color-scale to the list of available continuous color-scales. Not sure why this was done but to avoid breaking someone else's workflow, let's deprecate these first and completely drop support for it later on.

[sstephanyy]

Hello @tpvasconcelos. Could you provide guidance on which files or modules currently rely on the list_all_colorscale_names() function? I want to make sure I understand all the areas where this function impacts workflows...

[tpvasconcelos]

Hey @sstephanyy ! Thanks for your interest. Here's a quick todo of what needs to be done:

• Add a check in ridgeplot._ridgeplot::ridgeplot() to check if the user passed "default" to the colorscale argument. If so, raise a deprecation warning stating that this value is deprecated and support for it will be removed in a future version. Point the user to Plotly's px.colors.named_colorscales() to check which names are valid. Also link to this docs page: https://plotly.com/python/builtin-colorscales/#named-builtin-continuous-color-scales
• Add a deprecation warning in list_all_colorscale_names() and point users to use the Plotly Express function directly (px.colors.named_colorscales()). Also link to this docs page: https://plotly.com/python/builtin-colorscales/#named-builtin-continuous-color-scales
• Add tests for both of these changes. 👆
• Update the docstring for list_all_colorscale_names() and replace the .. versionadded:: with .. deprecated:: 0.1.31 and the same description as in the warning message.

Let me know if anything is not clear.

Also, please take a look at our Contributing Guide.

Thanks again! 🚀

[sstephanyy]

hey @tpvasconcelos!! Thank you so much for giving me the opportunity to contribute to this amazing project. I don't have so much experience, because I am still at a beginner-intermediate level, so I'm happy to learn more from you 😁

I have a question: What did you mean when you said to point users to use the Plotly Express function directly with (px.colors.named_colorscales())? Should I replace return sorted(ColorscaleValidator().named_colorscales) with return sorted(px.colors.named_colorscales())?

Should I create a new file just to test these changes?

Btw, your project is so well documented. Thanks very much for this!! 👏👏

[tpvasconcelos]

Hey @sstephanyy, thank you for the kind words. Happy to guide through your first contribution here.

To give you a bit more context here:

• Historically, our list_all_colorscale_names() function used to read from a local JSON file containing all the available continuous color scales.
• We have gradually moved towards a more consistent behaviour with Plotly Express and currently the function returns exactly the same as px.colors.named_colorscales() with the exception of the special "default" name that was added in the beginning of the project (not sure why) and hasn't been removed to avoid breaking someone's workflow.

btw you can confirm what I said above by running the following:

>>> from ridgeplot import list_all_colorscale_names
>>> import plotly.express as px
>>> set(list_all_colorscale_names()).symmetric_difference(set(px.colors.named_colorscales()))
{'default'}

• At this point I no longer see the need to have our own function since our API has evolved to accept any Plotly continuous colorscales and behave just like any Plotly Express figure factory function.
• In order to role this our gradually we first need to warn users that this functionality is going to be removed in a future version.
• The first step is to update the code to issue a deprecation warning whenever a user interacts with this functionality.

[tpvasconcelos]

Now to answer some of your questions...

What did you mean when you said to point users to use the Plotly Express function directly with (px.colors.named_colorscales())?

I just mean that since we are deprecating our own list_all_colorscale_names() function, we should let the users know that they should start using the px.colors.named_colorscales() function from Plotly Express to get this information. This should be made clear in the warning message as well as in the function's docstring (using the .. deprecated:: block that I mentioned before)

Should I replace return sorted(ColorscaleValidator().named_colorscales) with return sorted(px.colors.named_colorscales())

No, the functionality should stay the same for now. We are only changing the function's body to issue a deprecation warning for now.

Should I create a new file just to test these changes?

No need to create a new file. See here:

• Go to test_ridgeplot.py and look at the bottom of the file in the Deprecations section. Here you can add a test to check that when a user calls the ridgeplot() function with colorscale="default", a deprecation warning is issued. You can look at the other examples here for inspiration.
• Add another test in test_colorscale.py to test that the deprecation warning is issued when the list_all_colorscale_names() function is called.

[sstephanyy]

Hey @tpvasconcelos, thanks so much for the explanation. Now, I know exactly what you want me to do. I really appreciate it! :)

Could you help me out with something, please?

I've already made the changes you suggested, but I'm having trouble pushing them because I keep getting an error when I run the git commit message which automatically runs the pre-commit command. Do you have any idea what might be causing this? I've tried looking for a solution in the documentation and online, but I haven't had much luck. Basically, I'm unable to commit the changes...

The codespell was the only one that failed...

I have one more question: Should the pre-commit hook format the code automatically? I've been having a tough time trying to format my code manually to meet the requirements. 😆

[tpvasconcelos]

The codespell was the only one that failed...

Strange... looks like a Windows-specific problem. Are you committing via the terminal? If so, you can prefix your commit command with SKIP='codespell' or run:

export SKIP='codespell'
# Commit your stuff bellow. e.g.,
git commit -m 'my commit message'

I have one more question: Should the pre-commit hook format the code automatically? I've been having a tough time trying to format my code manually to meet the requirements. 😆

pre-commit runs both black and ruff which automatically format most of the code. However, there are specific things that ruff cannot fix automatically (such as breaking up long strings as in your example). Unfortunately, you'll have to fix these manually.

Let me know if you need any more help 🚀

(btw, from the screenshot above, your changes are looking good! 😉)

[tpvasconcelos]

Strange... looks like a Windows-specific problem

However, it looks like you're actually running Ubuntu no?