py-matplotlib: add v3.9.0

[adamjstewart]

New release of matplotlib that uses meson!

Before

Stage: 0.93s. Install: 31.12s. Post-install: 0.70s. Total: 32.91s

After

Stage: 0.95s. Install: 12.47s. Post-install: 0.65s. Total: 14.58s

[alalazo]

@adamjstewart Feel free to merge, if it seems ok to you. Not sure if you're waiting on a review from @rgommers

[adamjstewart]

Hmm, we seem to be building matplotlib 3.8.4 in CI instead. Any idea why?

[rgommers]

I don't see any obvious mistakes in the metadata, all LGTM. Prerequisites of 3.9.0 like meson-python and ninja are built, so no idea why 3.8.4 is selected.

[adamjstewart]

I'm able to reproduce this on the CLI.

> spack spec --fresh py-matplotlib

chooses matplotlib 3.9, but

> spack spec --fresh py-networkx

chooses matplotlib 3.8. Further investigation with spack solve reveals that choosing 3.9 results in more "version badness". This is because we depend on py-ninja instead of ninja, which forces us to use an older version of ninja. I think the easiest solution is to directly depend on ninja.

We've seen a lot of issues with py-cmake in the past. I wonder if we should remove py-cmake and py-ninja and only use the direct dependencies instead.

[alalazo]

I wonder if we should remove py-cmake and py-ninja and only use the direct dependencies instead.

I would be for that. Aren't they pip packaging of the corresponding tool, for convenience of pip users?

[rgommers]

Aren't they pip packaging of the corresponding tool, for convenience of pip users?

Yes they are. Agreed that depending on ninja is better.

[adamjstewart]

#44257

[adamjstewart]

Glad we tested newer matplotlib in CI because it's failing with the OneAPI compilers: https://gitlab.spack.io/spack/spack/-/pipelines/709134. Going to try re-enabling the hacks that were already there for this new version.

[adamjstewart]

@spackbot run pipeline

[spackbot-app]

I've started that pipeline for you!