chore(deps): Bumping Chroma version to 0.4.24

[tazarov]

What does this PR do?

Bumping Chroma version to latest stable 0.4.24

Why is it important?

The latest version introduces a number of bug fixes and improvements.

How to test this PR

Existing Chroma tests execute successfully.

--

I recently found out about your project and I think it is awesome. Keep up the good work

[netlify[bot]]

✅ Deploy Preview for testcontainers-go ready!

Name	Link
🔨 Latest commit	21fc274109db1c435561b6b2ee168d340722cb93
🔍 Latest deploy log	https://app.netlify.com/sites/testcontainers-go/deploys/65f98fb54e0584000948edc7
😎 Deploy Preview	https://deploy-preview-2391--testcontainers-go.netlify.app
📱 Preview on mobile	Toggle QR Code... Use your smartphone camera to open QR code link.

---

To edit notification comments on pull requests, go to your Netlify site configuration.

[mdelapenya]

Hi @tazarov, thanks for submitting this PR!

There is some context regarding the default versions that must be shared at some place from our side: we usually define a base image and let users use whatever image they need. In this particular case, the Chroma module does not add explicit logic for a given version, but there could be the case where we couple the implementation with a version (see Elasticsearch module as an example).

Said that, I'd prefer updating only the examples and tests instead of the default image of the module.

If this seems reasonable for you, I'll also update the example in the website here: https://github.com/testcontainers/community-module-registry/blob/4d037ebe011a53132bfca8ebd9f1984e13aa874b/modules/chroma/index.md?plain=1#L18

Thanks!

[tazarov]

@mdelapenya, thank you for the explanation.

Let me ask this. Do you think it makes sense that default versions should be the ones that solve the most problems for the users they serve? The Chroma team made a lot of progress between 0.4.22 and 0.4.24. The team feels strongly about DX, having sensible defaults (e.g., bumping versions) so that the out-of-the-box experience feels part of that DX-first mindset as best as it could.

That said, this is your project, and I have no objection to your comments. I am happy to close the PR or change the default to 0.4.22 in the chroma.go file.

[tazarov]

@mdelapenya, another point in case:

DONE 6 runs, 10 tests, 6 failures in 503.328s # 0.4.22
DONE 6 runs, 10 tests, 6 failures in 19.720s # 0.4.24

Note: Ignore the errors, I'm making another PR for the chroma-go lib

[tazarov]

@mdelapenya, I'm happy to update the docs. I have another PR with a few more examples and + a chroma-go client bump.

If you're ok with that, I can have the updated docs + the new PR out today.

[mdelapenya]

@mdelapenya, I'm happy to update the docs. I have another PR with a few more examples and + a chroma-go client bump.

If you're ok with that, I can have the updated docs + the new PR out today.

You can send the examples in a follow-up. If they are a demonstration for using the module, please use the testable examples pattern if possible 🙏 For me it's always difficult to create a testable example or a test, so I believe you'll find the place that makes sense to locate them 😅

[mdelapenya]

BTW, are you planing to add testcontainers-go to the chroma-go project? That would be fantastic! and I can help out if needed

[tazarov]

@mdelapenya, I recently encountered test containers (from the lanching project), and I'm super excited about what you are building. Yes, I want to add testcontainers to chroma-go. Using k8s for that (even a tiny distro like Minikube) is overkill and often flaky. I am also planning on adding test container examples to http://cookbook.chromadb.dev, as I think some Chroma users will be interested in figuring out how to test their GenAI stacks that include Chroma.

[mdelapenya]

I think this PR has been superseded by https://github.com/testcontainers/testcontainers-go/pull/2402. @tazarov can we close it?

[mdelapenya]

Closing as per https://github.com/testcontainers/testcontainers-go/pull/2391#issuecomment-2014993145

Thank you!