xref python/cpython#115398

I'm not too sure there is much for us to do here... the line in matplotlib that is failing is an import of a standard library module (plistlib).

In particular, the comment on the above thread that is directed to "Linux distro maintainers" indicates that care must be taken to ensure that (lib)expat and python are not out of sync with each other.

It looks like you are using conda, so the same caution would apply to the source of your python installation (either upstream anaconda main or e.g. conda forge) My first recommendation would be to ensure that all updates are applied, as a compatible expat appears to be available on conda.

It looks like conda forge does not provide a pin for expat version in the python recipe:

https://github.com/conda-forge/python-feedstock/blob/3732e621ad28b925e402c3c1d8542bac029920ad/recipe/meta.yaml#L181

All that said, and while I stand by my assessment that the primary problem is upstream packaging here, plistlib is, I believe, only actually used in MacOS specific code (other than the import)... so I think we could possibly move the import such that it doesn't happen on other platforms. I do believe you would still have problems with other xml tasks which use the stdlib module, though, so while the specific problem could be mitigated, it is not a full solution.

I see what you mean by standard library, however, the reason why matplotlib seemed implicated is because it's the dependency which changed yesterday (though we didn't go back and check mpl 3.8). But maybe that was just a coincidence?

Yes, we did introduce that import in this version, that much is true.

But I still think it is mostly just indicating a broken upstream package chain, that likely is fixed by ensuring upgrades are applied.

I tried this in a new environment:

$ conda create -p /tmp/foo python=3.11
$ conda activate /tmp/foo
$ python
>>> import plistlib

and it imports fine. Then I also tried with -c conda-forge to try those packages, and it also worked. This might be something specific to your environment, and I would try to be sure you are getting a completely clean environment.

Ah, ok, got it. 👍

We are able to address it like this:

sudo apt install libexpat1 libexpat1-dev

but it feels like I shouldn't need to do that. In our case, the travis config looks like this:

language: python
cache: pip
python: 3.11
dist: jammy

and then we use a more or less conventional conda installation (from miniconda).

The main suspect that I see in all that is that we're using jammy. Maybe that's just too old? Or that at some point someone will update it?

Ok, feel free to close this issue.

I would have expected you to get expat from conda, actually, but yeah, CPython introduced a version dependency on expat.

For me I was on python 3.12 and expat 3.6.2 on conda so I downgraded expat with conda install expat=3.6.1 which fixed it.