Maintaining testcontainers extensions #288
Description
The number of containers and interfaces supported by this package keeps growing (which is great!). However, that also means there are a lot of PRs both for adding containers, improving reliability and extending interfaces. Consequently, I sometimes struggle to keep on top of them, especially during holidays.
I've been pondering on how we might be able to decouple parts of the codebase, e.g., by introducing separate packages for separate (classes of) containers, such that my bandwidth isn't the limiting factor for development. Some options are listed below, and I'd be keen to get feedback before making any changes. To maintain (some) backwards compatibility, we could introduce a "metapackage" package as used by the jupyter project.
| Approach | 👍 Pros | 👎 Cons |
|---|---|---|
| Keep things as is | no changes | slow development; large-ish amount of work for me and other maintainers |
| Monorepo with multiple namespace packages | can update container-specific packages without bumping all of testcontainers-python; faster development and easier for others to contribute (by using CODEOWNERS for different packages); less work for me |
one-off setup work; possible code duplication; possible version conflicts (e.g., test might pass on master but not for released packages) |
| Separate repos with one namespace package each | as above + a lot less work for me; complete freedom for maintainers of other packages | as above + fragmentation of the ecosystem; some containers likely to be abandoned |
I'm currently leaning towards a monorepo with namespace packages as in Google's cloud packages for python but would be keen to hear from others before making any changes.