bug: community modules using old decorators print deprecation warnings

[DarthMax]

It seems that the 4.13 release introduced a new deprecation warning around the @wait_container_is_ready decorator.

The deprecation warning itself works as expected and the description is comprehensive.
There is a problem however: importing DockerContainer will cause the deprecation warning to appear with the following stack trace:

conftest.py:6: in <module>
 from testcontainers.core.container import DockerContainer
project/venv/lib/python3.13/site-packages/testcontainers/core/container.py:21: in <module>
 from testcontainers.core.wait_strategies import LogMessageWaitStrategy
project/venv/lib/python3.13/site-packages/testcontainers/core/wait_strategies.py:41: in <module>
 from .waiting_utils import WaitStrategy, WaitStrategyTarget
project/venv/lib/python3.13/site-packages/testcontainers/core/waiting_utils.py:178: in <module>
 @wait_container_is_ready()
project/venv/lib/python3.13/site-packages/testcontainers/core/waiting_utils.py:117: in wait_container_is_ready
 warnings.warn(
E DeprecationWarning: The @wait_container_is_ready decorator is deprecated and will be removed in a future version. Use structured wait strategies instead: container.waiting_for(HttpWaitStrategy(8080).for_status_code(200)) or container.waiting_for(LogMessageWaitStrategy('ready'))

Our project is configured to treat warnings as errors. As far as I am aware, there is currently nothing we can do on the consumer side to prevent this issues.

As a side note, the documentation still mentions the wait_for_logs method:
https://testcontainers-python.readthedocs.io/en/latest/core/README.html

To Reproduce

from testcontainers.core.container import DockerContainer

template details

Runtime environment

Provide a summary of your runtime environment. Which operating system, python version, and docker version are you using? What is the version of testcontainers-python you are using? You can run the following commands to get the relevant information.

# Get the operating system information (on a unix os).
$ uname -a
Linux computer 6.16.5-arch1-1 #1 SMP PREEMPT_DYNAMIC Thu, 04 Sep 2025 23:18:13 +0000 x86_64 GNU/Linux
# Get the python version.
$ python --version
Python 3.13.7
# Get the docker version and other docker information.
$ docker info
Client:
 Version: 28.3.3
 Context: default
 Debug Mode: false
 Plugins:
 compose: Docker Compose (Docker Inc.)
 Version: 2.39.2
 Path: /usr/lib/docker/cli-plugins/docker-compose

Server:
 Containers: 18
 Running: 0
 Paused: 0
 Stopped: 18
 Images: 89
 Server Version: 28.3.3
 Storage Driver: overlay2
 Backing Filesystem: btrfs
 Supports d_type: true
 Using metacopy: true
 Native Overlay Diff: false
 userxattr: false
 Logging Driver: json-file
 Cgroup Driver: systemd
 Cgroup Version: 2
 Plugins:
 Volume: local
 Network: bridge host ipvlan macvlan null overlay
 Log: awslogs fluentd gcplogs gelf journald json-file local splunk syslog
 CDI spec directories:
 /etc/cdi
 /var/run/cdi
 Swarm: inactive
 Runtimes: io.containerd.runc.v2 runc
 Default Runtime: runc
 Init Binary: docker-init
 containerd version: 75cb2b7193e4e490e9fbdc236c0e811ccaba3376.m
 runc version: 
 init version: de40ad0
 Security Options:
 seccomp
 Profile: builtin
 cgroupns
 Kernel Version: 6.16.5-arch1-1
 Operating System: Arch Linux
 OSType: linux
 Architecture: x86_64
 CPUs: 22
 Total Memory: 62.23GiB
 Name: kaylee
 ID: 255a32ed-e357-4e07-be9f-c97413711ef9
 Docker Root Dir: /var/lib/docker
 Debug Mode: false
 Experimental: false
 Insecure Registries:
 ::1/128
 127.0.0.0/8
 Live Restore Enabled: false

[antonio-carapcea-softwire]

We get this as well just by using testcontainers in a fixture.

[mitch-karch]

+1, seems to be an issue when we utilize the provided redis container in a fixture

[johnniemorrow]

Same with testcontainers.postgres.PostgresContainer

[dbogdoll]

+1

[alexanderankin]

yep, we upgraded core to use a sane abstraction and still need to update the community modules. deprecation warnings are ok, they communicate that something is going away, not that it is broken.

[porn]

MongoDbContainer also affected (from testcontainers.mongodb import MongoDbContainer) ℹ️

[fan9704]

Same with testcontainers.postgres.PostgresContainer

[dudustri]

well, apparently if you call the test container in general during import time it will break your module due to the warning for newer python versions 3.12 or above (tighten restriction of deprecation). I would recommend to downgrade the test containers package in this meanwhile since I couldn't figure out how to make it work either with a lazy instantiation or module import. I think it is happening with most of the test containers if not all. In my case it happened with Redis, MySQL, regular docker and Arango.

Does someone have a workaround for it while the guys are on a wip with the community modules?

[alexanderankin]

is there any reference or example I can look at for python 3.12 deprecation behavior? this is something I was not aware of, and changes the severity of this bug.

Just to be clear, if someone is treating warnings as errors in their code, and they do not have the ability to turn this off for libraries, that is their problem and i am not going to fix it. (Can't, also - won't).

But if there is some kind of mechanism built into python that treats warnings as errors, and basically CPython is forcing all of us to treat warnings as errors in some particular context that is not easy to work around, then we will adjust testcontainers to communicate deprecations in a way which is not sabotaged by the language itself.

my goal is to communicate that a deprecated API is in use, not to make it really annoying to use the deprecated API. I am fully aware of when sometimes it is appropriate to use a deprecated API.

[alexanderankin]

edited to clarify i mean to ask about python treating warnings as errors. does python do this or is this just a thing people do in projects. people should not do this in projects. but if python itself does this, ill work around that somehow here.

[DarthMax]

I do not think this is something Python does in general. In our project we have a build that runs with that setting, so that we are notified about new deprecations.
The problem with this situation, is that there is nothing we can do to get rid of the deprecation.
As I initially described, we are not using a community module but simply import DockerContainer.

[mitch-karch]

Just for fun, I have this in my pyproject.toml to help suppress this specifically for my test cases

[tool.pytest.ini_options]
filterwarnings = [
 "ignore:^The @wait_container_is_ready decorator:DeprecationWarning"
]