Include tzdata-legacy in python slim images after move to Debian Trixie?

[gibsondan]

This may be an expected breaking change, but running the following python code in python:slim stopped working yesterday with the move to Debian Trixie :

>> from zoneinfo import ZoneInfo
>> ZoneInfo("US/Central")

Traceback (most recent call last):
  File "/usr/local/lib/python3.10/zoneinfo/_common.py", line 12, in load_tzdata
    return importlib.resources.open_binary(package_name, resource_name)
  File "/usr/local/lib/python3.10/importlib/resources.py", line 43, in open_binary
    package = _common.get_package(package)
  File "/usr/local/lib/python3.10/importlib/_common.py", line 66, in get_package
    resolved = resolve(package)
  File "/usr/local/lib/python3.10/importlib/_common.py", line 57, in resolve
    return cand if isinstance(cand, types.ModuleType) else importlib.import_module(cand)
  File "/usr/local/lib/python3.10/importlib/__init__.py", line 126, in import_module
    return _bootstrap._gcd_import(name[level:], package, level)
  File "<frozen importlib._bootstrap>", line 1050, in _gcd_import
  File "<frozen importlib._bootstrap>", line 1027, in _find_and_load
  File "<frozen importlib._bootstrap>", line 992, in _find_and_load_unlocked
  File "<frozen importlib._bootstrap>", line 241, in _call_with_frames_removed
  File "<frozen importlib._bootstrap>", line 1050, in _gcd_import
  File "<frozen importlib._bootstrap>", line 1027, in _find_and_load
  File "<frozen importlib._bootstrap>", line 992, in _find_and_load_unlocked
  File "<frozen importlib._bootstrap>", line 241, in _call_with_frames_removed
  File "<frozen importlib._bootstrap>", line 1050, in _gcd_import
  File "<frozen importlib._bootstrap>", line 1027, in _find_and_load
  File "<frozen importlib._bootstrap>", line 1004, in _find_and_load_unlocked
ModuleNotFoundError: No module named 'tzdata'

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/usr/local/lib/python3.10/zoneinfo/_common.py", line 24, in load_tzdata
    raise ZoneInfoNotFoundError(f"No time zone found with key {key}")
zoneinfo._common.ZoneInfoNotFoundError: 'No time zone found with key US/Central'
>

This could break existing users that are depending on those timezone strings being available like they were before. This is apparently an expected change in Trixie that installing the tzdata-legacy package would resolve, so throwing that out as a possible mitigation.

[gibsondan]

This was moved to python, but I don't think the issue is exclusive to Python - the tzdata-legacy package that I mentioned is a debian package not a Python one.

[yosifkit]

https://github.com/docker-library/python/blob/47950d2d110d6f23a8640bcfc9d07185dd8cf4d6/Dockerfile-linux.template#L50

🤔 We do explicitly install tzdata in the slim images (and it is also in the non-slim), but I am unsure if that means we should also install the tzdata-legacy package or not. These are obsolete time zone names, so I lean toward not installing it and letting users either install it themselves or stick to the -bookworm images.

python:<version>-slim

This image does not contain the common Debian packages contained in the default tag and only contains the minimal Debian packages needed to run python.

- Docker Hub docs

This doesn't affect the general running of python and is "just" when users try to use obsolete time zone names.

---

This was moved to python, but I don't think the issue is exclusive to Python - the tzdata-legacy package that I mentioned is a debian package not a Python one.

This Debian Trixie change may affect other images (https://github.com/docker-library/postgres/issues/1355), but this is about what to do in the python image.

[gibsondan]

This Debian Trixie change may affect other images (docker-library/postgres#1355), but this is about what to do in the python image.

Ah right, sorry, that makes sense.

[tianon]

Agreed, my understanding is that these aliases have been considered "legacy" and secondary for many years now, and that's finally reflected appropriately in the packaging, and it's trivial for downstream users to either update their aliases or install the additional package, so I don't think we should do so in the base image.

[tarujg]

Thanks. This was surfacing in my staging environment. Saved me an issue just in time.

Note to self: version tag the images.