libexpat not packaged with linux wheels?

[mathause]

It looks like libexpat is not packaged in linux wheels. However, from build_expat I would expect it to be - or do I interpret the IS_OSX flag wrong?

rasterio-wheels/config.sh

Line 155 in c04fa87

function build_expat {

Why is that relevant? Apparently some linux docker images stopped shipping libexpat (see docker-library/python#984) so importing rasterio fails in these containers.

[vincentsarago]

I also just experienced it with AWS Lambda python 3.12, but I've not yet be able to create a simple reproductible example developmentseed/titiler-md-demo#3

[AdelImamovic]

Code to reproduce the issue:

podman pull docker.io/library/python:3.10-slim # same with py311
podman run python:3.10-slim sh -c "pip install rasterio && python -c 'import rasterio'"

[sgillies]

Thanks for the report @mathause ! I don't think I'll do anything about it just for these particular images.

Keep in mind that the rasterio wheels are mostly for testing purposes. I don't put them into production because they lack features and some of the library versions are a little old.

[mathause]

Thanks for your answer. So what's the recommendation? Using conda? Or building locally?

It's obviously fair enough that the wheels should not be used for production - but where could I see that? Is that in the documentation? (And just as a comment: it's quite the recommendation for the individual user to know which package on the stack is usable and which is not. Especially if it had recent versions on pypi.)

[vincentsarago]

this was also reported in rasterio/rasterio#3257 (reply in thread) and is linked to docker-library/python#989

@mathause the easiest thing to do is to install libexpat

apt update && apt install -y libexpat1

[sgillies]

Thanks @vincentsarago ! I'll close this as it is all in the hands of the slim image maintainers.

It's not surprising that rasterio wheels users saw this first. Rasterio's C dependencies are probably the most numerous of any publicly published wheels.