testcontainers
bug: community modules using old decorators print deprecation warnings
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
We get this as well just by using testcontainers in a fixture.
+1, seems to be an issue when we utilize the provided redis container in a fixture
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.
MongoDbContainer also affected (from testcontainers.mongodb import MongoDbContainer) ℹ️
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?
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.
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.
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.
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"
]
@alexanderankin The module testcontainers.core.waiting_utils still defines on module level the wait_for function, which is decorated with @wait_container_is_ready, which causes a FutureWarning to be raised at import time. The module also has some of the "new" abstractions i.e. the WaitStrategy ABC, so I don't think it should be raising FutureWarnings on import.
For anyone fixing these, the docs still reference this deprecated method:
https://github.com/testcontainers/testcontainers-python/blob/5853d326bb4e9631b7c58355c53ff7fc3ecab92d/docs/features/wait_strategies.md?plain=1#L7-L17
