Hi everyone, I'm Ahmed, really love the work you guys did, especially the speed on which you push updates, I use wiremock quite a bit and I like to think I have enough knowledge around wiremock to work with it on the python version (cause I hate development in java), I have a couple of questions regarding the repo and what I should start with ( and bare with me here, I'm familiar with git and github but new to opensource in general ) what grabbed my attention was this issue: • here Oleg mentions that we need integrations tests for native implementation yet here it is suggested that we want to remove native implementations, which should we consider? • in the same issue

Integration testing with WireMock 3 in the Testcontainers module

is one of the tasks, is there a list of features ? or a testsuite and lets me know how much is needed to cover ?, how should I just go around trying every feature that I could find ?, also what's the acceptance criteria for such a task ? I also wanted to ask about the next two points, but I think these questions above are a great starting point! (I hope) looking forward to continuing the python implementation and contributing to this amazing project

Hi, thanks for your interest in helping with this. I haven’t looked at this for a while, but I think where we are currently is: • The Python lib is only using 2.x features (for the most part at least) so some tests and probably corresponding production code changes are needed to take advantage of 3.x features. • Basic Testcontainers implementation is working well but we’re lacking specific Python bindings for most of the startup options meaning you have to construct CLI parameters instead (which isn’t a great experience). • Community feedback about the native version is that folks don’t like having a big Java JAR baked into the distribution so I think we’d be better off removing this and focusing on the two other use cases - connecting to a remote server and Testcontainers. This does present a bit of a backwards compatibility issue though, so we could do something along the lines of downloading the JAR on demand if you explicitly choose that strategy, rather than having it there all the time.