DOC/BLD: make logo compatible with pydata-sphinx-theme

[jklymak]

PR Summary

Now that pydata-sphinx-theme is out, it is compatible with mpl-sphinx-theme.

Note we are still using mpl-sphinx-theme from git.

PR Checklist

Documentation and Tests

• Has pytest style unit tests (and pytest passes)
• Documentation is sphinx and numpydoc compliant (the docs should build without error).
• New plotting related features are documented with examples.

Release Notes

• New features are marked with a .. versionadded:: directive in the docstring and documented in doc/users/next_whats_new/
• API changes are marked with a .. versionchanged:: directive in the docstring and documented in doc/api/next_api_changes/
• Release notes conform with instructions in next_whats_new/README.rst or next_api_changes/README.rst

[tacaswell]

matplotlib/.circleci/config.yml

Lines 98 to 104 in c8b5a2a

	name: Install Python dependencies
	command: |
	python -m pip install --no-deps --user \
	git+https://github.com/matplotlib/mpl-sphinx-theme.git
	python -m pip install --user \
	numpy<< parameters.numpy_version >> codecov coverage \
	-r requirements/doc/doc-requirements.txt

is where we are setting up the environment on circle.

We may want to re-order that just to be safe in case pip becomes more helpful and downgrades mpl-sphinx-theme in the future.

[jklymak]

Huh, I don't think this is working - the built logo doesn't change from light to dark. Regardless, I think it can be fixed in mpl-sphinx-theme.

[jklymak]

We may want to re-order that just to be safe in case pip becomes more helpful and downgrades mpl-sphinx-theme in the future.

Oh, OK, I think this is int he wrong order for sure. Because we are now pinning mpl-sphinx-theme, we need to git-install after.

[tacaswell]

ah, sorry I jumped the gun on merging this!

[jklymak]

I think it's just CI that is broken? Should we be putting the git+ pin in doc-requirements.txt so that when you guys build the dev docs mpl-sphinx-theme is used, or should we just release a 3.7.1 mpl-sphinx-theme.

I think there advantages to having these things modular, but juggling the dependencies does seem to be a bit of a pain.

[tacaswell]

The motivation for going to hard-pins is that now when we make releases the last working set of pins goes to the maintenance branch with no extra work. The cost is now we have moved this pinning to be a development-time activity.

This might actually be a good use-case for the depndabot auto-dep bumper, but I suspect that unless one of the core devs already uses it in other contexts it will be more work to learn how to use it than to just bump the versions.

Of course installing from git in CI defeats a bunch of that logic so maybe we should drop that and always rely on released versions of mpl-sphinx-theme?

We probably should go the "release from CI" route on that package to make it super easy to make new releases....

[jklymak]

I'm happy with whatever works. We basically have three clients?

1. the stable docs (3.7.x) which can/should be pinned to mpl-sphinx-theme 3.7 (and pydata-sphinx-theme 0.12)
2. the dev docs
3. CI which I've now pinned to git+mpl-sphinx-theme (mst)

I think we could make a 3.8.dev release of mpl-sphinx-theme that 2 and 3 follow until 3.8 is released, and then release a 3.8.0 of mpl-sphinx-theme?

We probably should go the "release from CI" route on that package to make it super easy to make new releases....

Yeah, if we have a 3.8.dev release, some sort of automated way to do that from an updated branch or some such would be great. I'm happy to tackle that if you like, but I suspect @QuLogic or @ksunden would know how to do it properly.