-
Notifications
You must be signed in to change notification settings - Fork 283
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Dependencies: Stop bundling client libraries #526
Comments
I had an approach for the recently added
Couple other thoughts
|
I still think we should include the client libraries as
Yupp, and if the images come bundled with tools intended for readiness checking I think we can utilize that more to actually perform readiness checking. Parsing logs are okay, but not always ideal, especially if there is no message where it is abundantly clear that the message is meant to indicate that the container is ready.
I think we misunderstood each other a little here. I still would like to include client libraries as
Agreed. |
…ault wait timeout for `wait_for_logs` (#525) Removes usage of `sqlalchemy`, as part of the work described in #526. - Adds default timeout to the `wait_for_logs` waiting strategy, the same timeout used by default in the `wait_container_is_ready` strategy. - Changes wait strategy for `mysql` container to wait for logs indicating that the DB engine is ready to accept connections (MySQL performs a restart as part of its startup procedure, so the logs will always appear twice. - Add More tests for different `mysql` and `mariadb` versions to ensure consistency in wait strategy. - Remove x86 emulation for ARM devices for MariaDB, as it MariaDB images support ARM architectures already. - Change wait strategy for `oracle-free`, as the images produce a consistent `DATABASE IS READY TO USE!` log message on startup. Next steps will be to remove `sqlalchemy` as a bundled dependency entirely, but I have not included it in this PR as I consider it a bigger change than just changing wait strategies as an internal implementation detail. I plan to do this as part of a bigger rework where i remove the `DbContainer` class and standardize configuration hooks and wait strategies across containers (not just DB containers, all containers in need of a configuration and readiness step). See #527 for WIP. --------- Co-authored-by: David Ankin <[email protected]>
When installing some of our community modules through
extras
, we usually bundle a client library for interacting with the service provided from the container. In some cases this is nice, as there is only a single, official client library available for that service (E.g.qdrant-client
).However, in many cases there is no single client library that makes for the best choice. Some examples are
sqlalchemy
in combination with other drivers for connecting to databses, where you have the choice between multiple drivers (such aspyodbc
andpymssql
for SQL Server,pg8000
andpsycopg
for Postgres and so on). Many use cases don't even usesqlalchemy
for their database connection, and we are thus forcing an install of one or more useless packages in their builds.Therefore I suggest that we remove all dependencies for client libraries in our
extras
and put the responsibility for connecting to the containers with their chosen framework on the users of tc-python. We will still keep client libraries as part of ourdev
dependencies, so that we can provide usage examples in our doctests and other documentation, but simply installingtestcontainers-python
with some extras will no longer give you a large bundle of dependencies you might not need.Where possible, we will still include and maintain methods such as
get_connection_string
(and variants, where we should probably standardize on a naming convention for consistency) for easy usage with client libraries. Example usage with client libraries also become more important, but in those examples we always show imports of the client library used, so it should be quite self-explanatory that you need a client to connect to a service.This work has already been partly started, and contain useful discussion around the issue. See here for the work done on removing
sqlalchemy
from Postgres.The text was updated successfully, but these errors were encountered: